Yaroslav Halchenko [off-list ref] writes:
and that is where the gotcha comes -- what if "my" changes were already
published? then I would like to avoid the rebase, and would -s theirs
to choose "their" solution in favor of mine and be able to push so
others could still "fast-forward" to the new state.
So -- as to me it remains 'symmetric' ;)
I do not necessarily agree. Once you decide that their history is
the mainline, you'd rather want to treat your line of development as
a side branch and make a merge in that direction, i.e. the first
parent of the resulting merge is a commit on their history and the
second parent is the last bad one of your history. So you would end
up using "checkout their-history && merge -s ours your-history" to
keep the first-parenthood sensible.
And at that point, use of "-s ours" is no longer a workaround for
lack of "-s theirs". It is a proper part of the desired semantics,
i.e. from the point of view of the surviving canonical history line,
you want to preserve what it did, nullifying what the other line of
history did.
So I still do not think the above scenario justifies "-s theirs".
On Wed, 27 Sep 2017, Junio C Hamano wrote:
quoted
and that is where the gotcha comes -- what if "my" changes were already
published? then I would like to avoid the rebase, and would -s theirs
to choose "their" solution in favor of mine and be able to push so
others could still "fast-forward" to the new state.
quoted
So -- as to me it remains 'symmetric' ;)
I do not necessarily agree. Once you decide that their history is
the mainline, you'd rather want to treat your line of development as
a side branch and make a merge in that direction, i.e. the first
parent of the resulting merge is a commit on their history and the
second parent is the last bad one of your history. So you would end
up using "checkout their-history && merge -s ours your-history" to
keep the first-parenthood sensible.
And at that point, use of "-s ours" is no longer a workaround for
lack of "-s theirs". It is a proper part of the desired semantics,
i.e. from the point of view of the surviving canonical history line,
you want to preserve what it did, nullifying what the other line of
history did.
So I still do not think the above scenario justifies "-s theirs".
ok, when you describe it like this (in my case I rarely cared about the
side of the merge), then indeed I might better do the entire dance with
git reset --hard theirstate; git merge -s ours HEAD@{1}
and live happily with the left side being the one always correct and
hide "my" mistakes ;) will keep it in mind
--
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
On Wed, 27 Sep 2017, Yaroslav Halchenko wrote:
quoted
And at that point, use of "-s ours" is no longer a workaround for
lack of "-s theirs". It is a proper part of the desired semantics,
i.e. from the point of view of the surviving canonical history line,
you want to preserve what it did, nullifying what the other line of
history did.
quoted
So I still do not think the above scenario justifies "-s theirs".
ok, when you describe it like this (in my case I rarely cared about the
side of the merge), then indeed I might better do the entire dance with
git reset --hard theirstate; git merge -s ours HEAD@{1}
and live happily with the left side being the one always correct and
hide "my" mistakes ;) will keep it in mind
ha -- was about to use it, which reminded me about this use case!
NB pardon me for not so wonderful ascii-diagrams as yours but hopefully
still helps
x-o-o-o-x-o-o debian
/ /
x-------x----- releases -- should just linearly sweep through releases I care about
/ /
R1 R2 various release branches/tags
A B which have differing commits
/ /
---o---o----o----o masteg
For packaging some packages for Debian, with my git-rotten-soul, I am trying to
keep my debian packaging (in a branch "debian") on top of upstream
releases. But the problem comes whenever upstream releases from "release
branches", which are never merged into master and might have different and
conflicting changes.
So, it becomes impossible to maintain a linearly progressing "debian"
branch without adding a middle-man between upstream releases (in release
branches), and debian branch (should progress linearly forward) -- "releases"
branch. See e.g. http://github.com/neurodebian/pandas and its releases
branch.
so I use -s theirs for "linearizing" the branched up development history
--
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik