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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 26, 2017, 03:45 UTC
Message-ID: <xmqqzi9iazrp.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170925144021.vhbd3wb3uqejs5wq@hopa.kiewit.dartmouth.edu>

Yaroslav Halchenko <yoh@onerussian.com> writes:

Show 9 quoted lines

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

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

where 'X' denotes those unwanted changes.

With a "-s ours" merge, you can declare that changes on the other branch will never be merged to your branch, i.e.

                 B---C
                /
           X---X---A
          /     \
      ---o---o---M     your mainline

and then you can safely merge A and C into your branch, without having to worry about them bringing the unwanted changes to your tree state.

                 B---C
                /     \
           X---X---A   \
          /     \   \   \
      ---o---o---M---N---O  your mainline

That is the primary reason why "-s ours" exists, i.e. you do not control the branch where mistakes X were made because that is somebody else's history.

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:

                 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.

               B'--C'
              /  
      ---o---o---A'

The reason why ours and theirs are not symmetric is because you are you and not them---the control and ownership of our history and their history is not symmetric.

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.