Strategy 'theirs' is described in help page for git merge:

$> git merge --help | grep -A1 '^\W*theirs$'
           theirs
               This is opposite of ours.

but isn't actually available:

$> git merge -s theirs MDP-2.6
Could not find merge strategy 'theirs'.
Available strategies are: octopus ours recursive resolve subtree.

so now I need to simulate it via some branch renames and -s ours

# [1]
forwarded 581680 http://thread.gmane.org/gmane.comp.version-control.git/89022/focus=89024
retitle 581680 provide merge strategy 'theirs'
severity 581680 wishlist
clone 581680 -1
retitle -1 user-defined merge strategies do not kick in for trivial merges
severity -1 normal
tags -1 upstream
thanks

Hi Yaroslav,

Yaroslav Halchenko wrote:


It should be simple to roll your own, by starting with
/usr/share/doc/git/contrib/examples/git-merge-ours.sh and changing it
to read-tree -m -u --aggressive the second argument after the first "--",

 $ git merge-ours -h
 usage: git merge-ours <base>... -- HEAD <remote>...

then putting it in your $PATH under the name git-merge-theirs.
Unfortunately, a separate bug prevents this being very useful: the
built-in merge command "optimizes" the merge by not even invoking
the merge strategy in trivial cases, since the NO_TRIVIAL flag is not
set for user-defined merges for some reason.  Agh (I will look into
writing a patch for that tomorrow).

Okay, so if it's so easy to provide a "theirs", why doesn't git
already?  See [1] above.  Short answer: because it's almost always the
wrong thing to use.

A patch that includes documentation explaining what this is useful for
would still be welcome.

Thanks for the report.  Hope that helps,
Jonathan

Jonathan,

THANK YOU lots for your exhaustive reply and handing of the wishlist.
that is what I thought since ours is there
yeap -- it is wrong thing to use in 99.999% of merges... but in that
0.001 it might come useful (like "joining" two development paths
deciding to go with "the other" one from now on).
yes -- in many respects, thanks again