git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Yaroslav Halchenko <yoh@onerussian.com>
To: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: BUG: merge -s theirs  is not in effect (does the same as -s ours)
Date: Sun, 24 Sep 2017 23:17:51 -0400	[thread overview]
Message-ID: <20170925031751.lg7zk6krt65dxwas@hopa.kiewit.dartmouth.edu> (raw)
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:

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

  reply	other threads:[~2017-09-25  3:18 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-25  0:02 BUG: merge -s theirs is not in effect (does the same as -s ours) Yaroslav Halchenko
2017-09-25  1:08 ` Junio C Hamano
2017-09-25  3:17   ` Yaroslav Halchenko [this message]
2017-09-25  5:33     ` Re* " Junio C Hamano
2017-09-25 14:30       ` -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect Yaroslav Halchenko
2017-09-26  1:56         ` Junio C Hamano
2017-09-26  2:16           ` Junio C Hamano
2017-09-26  2:39             ` Junio C Hamano
2017-09-26 13:37               ` Yaroslav Halchenko
2017-10-16  5:38                 ` [PATCH] merge: teach -Xours/-Xtheirs to symbolic link merge Junio C Hamano
2017-12-29  2:49                   ` Elijah Newren
2017-12-29  4:41                     ` Yaroslav Halchenko
2018-01-25  4:35                   ` external diff driver is not used for diff --stat? Yaroslav Halchenko
2017-09-25 14:40       ` -s theirs use-case(s) Was: BUG: merge -s theirs is not in effect Yaroslav Halchenko
2017-09-26  3:45         ` Junio C Hamano
2017-09-26 13:32           ` Yaroslav Halchenko
2017-09-27  0:09             ` Junio C Hamano
2017-09-27  5:19               ` Yaroslav Halchenko
2017-09-27 20:21                 ` Yaroslav Halchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170925031751.lg7zk6krt65dxwas@hopa.kiewit.dartmouth.edu \
    --to=yoh@onerussian.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).