Re: BUG: merge -s theirs is not in effect (does the same as -s ours)

From: Yaroslav Halchenko <yoh@onerussian.com>
Date: Sep 25, 2017, 03:17 UTC
Message-ID: <20170925031751.lg7zk6krt65dxwas@hopa.kiewit.dartmouth.edu>
In-Reply-To: <xmqqwp4nfuv1.fsf@gitster.mtv.corp.google.com>

On Mon, 25 Sep 2017, Junio C Hamano wrote:

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

Show 5 quoted lines

> > My interest was to get remote branch "merge" the changes in the
> > branch taking the branch's version (primarily alternative symlinks
> > for git-annex'ed content) over the version in master (previous
> > merge of a similar branch).  Unfortunately -s theirs seems to do
> > actually -s ours

> What does

>     ls $(git --exec-path) | grep git-merge

NB when running git just built, --exec-path reports some non existing dir in ~:

$> git --exec-path /home/yoh/libexec/git-core $> ls -l /home/yoh/libexec/git-core ls: cannot access '/home/yoh/libexec/git-core': No such file or directory $> which git /home/yoh/proj/misc/git/git

> say?

> The official Git never shipped "git-merge-theirs" as far as I know,
> and it should not exist (neither should "git merge -s theirs"; you
> can use "git reset --hard theirs" instead).

d'oh, indeed there is no git-merge-theirs neither in debian pkg or a freshly built git and I found a rogue script in the PATH (which did nothing apparently, sorry!). BUT I was originally mislead by the --help/manpage:

MERGE STRATEGIES
       The merge mechanism (git merge and git pull commands) allows the backend merge strategies to be chosen with -s option. Some strategies can also take their own options, which can be passed by giving -X<option>
       arguments to git merge and/or git pull.
       ...
       recursive
           This can only resolve two heads using a 3-way merge algorithm. When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as
           the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development
           history. Additionally this can detect and handle merges involving renames. This is the default merge strategy when pulling or merging one branch.

           The recursive strategy can take the following options:

           ours
               This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. ...
           theirs
               This is the opposite of ours.

(Documentation/merge-strategies.txt in the sources I guess)

PS thanks for CCing me in replies!

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