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

[Junio C Hamano <gitster@pobox.com>]

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:

                 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.