Re: -s theirs use-case(s) Was: BUG: merge -s theirs is not in effect

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 27, 2017, 00:09 UTC
Message-ID: <xmqqzi9h80jp.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170926133232.3yjasune6um4qw45@hopa.kiewit.dartmouth.edu>

Yaroslav Halchenko <yoh@onerussian.com> writes:

Show 6 quoted lines

> 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".