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

From: Yaroslav Halchenko <yoh@onerussian.com>
Date: Sep 26, 2017, 13:32 UTC
Message-ID: <20170926133232.3yjasune6um4qw45@hopa.kiewit.dartmouth.edu>
In-Reply-To: <xmqqzi9iazrp.fsf@gitster.mtv.corp.google.com>

On Tue, 26 Sep 2017, Junio C Hamano wrote:

> Yaroslav Halchenko <yoh@onerussian.com> writes:

> > 1. As a workaround for absence of -m theirs I using mtheirs git alias:
> > (I believe provided to me awhile back here on the list):

> >     mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u $1' -

> > and it worked fine for my usecases

> > 2. I think that if there is a reason for -s ours to exist, so there for -s theirs
> > since it is just the directionality of merges which changes between the two

> Just on this point.  They are not exactly symmetric.

> Imagine there are some undesirable changes you want to vanquish from
> the world, but they have already built on useful changes on top of
> the undesirable changes.  A hypothetical history might look like
> this:

Show 5 quoted lines

>                  B---C
>                 /
>            X---X---A
>           /
>       ---o---o         your mainline

> where 'X' denotes those unwanted changes.

> >...<

> The symmetiric case where _you_ have wrong changes do not need "-s
> theirs".  These mistakes X are yours, so are the changes depend on
> them:

Show 5 quoted lines

>                  B---C
>                 /
>            X---X---A
>           /
>       ---o---o         their mainline

> and you can just rebase A, B and C on top of their mainline while
> getting rid of Xs yourself before publishing.

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' ;)

Show 10 quoted lines

> There may be valid workflows that benefit from "-s theirs", and I
> would not be surprised at all if we found more of them in the past 9
> years since we had the "why -s theirs does not exist" discussion in
> 2008.  But "because -s ours can be used in reverse to emulate" is
> not a valid excuse to add "-s theirs".  It can be used a rationale
> against adding it (e.g. "-s theirs generally is discouraged because
> it forsters a bad workflow, but in a very rare case where it might
> be useful, you can always check out their branch and merge yours
> using '-s ours' to emulate it, so we do not lose any functionality
> even if we did not add it"), though.

sure, git is flexible, so workarounds could always be found, but often many options are just a matter of convenience. And here -s theirs would be one of them besides my other use case where it is a somewhat "by design" workflow, and -s theirs is use to take their exact state I would improve upon (before committing the "merge")

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