From: Junio C Hamano <gitster@pobox•com>
To: Yaroslav Halchenko <yoh@onerussian•com>
Cc: "git\@vger.kernel.org" <git@vger•kernel.org>
Subject: Re: -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect
Date: Tue, 26 Sep 2017 10:56:32 +0900 [thread overview]
Message-ID: <xmqqing6cje7.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170925143040.4qgofxcdahal46r7@hopa.kiewit.dartmouth.edu> (Yaroslav Halchenko's message of "Mon, 25 Sep 2017 10:30:40 -0400")
Yaroslav Halchenko <yoh@onerussian•com> writes:
> yes it does. Thanks. And that is where I realized that I should have used -X
> theirs (not -s theirs), as the instruction on the option for the
> (recursive) merge. And now problem is more specific:
>
> - conflict within file content editing was resolved as instructed
> (taking "theirs" version)
>
> - BUT symlink was not taken from "theirs" and left as unresolved conflict:
I wouldn't call it working-as-intended, but this unfortunately is
expected. You'd encounter exactly the same behaviour when changes
to a binary file conflicts.
It is because -X<ours|theirs> _ONLY_ kicks in (i.e. that is how it
is defined) when we would otherwise throw the half-merged result:
<<<<<<<
our version looks like this
=======
their version looks like this
>>>>>>>
and ask you to edit that to a correct resolution.
Because you would not normally be given something like the above
when merging conflicted changes to symbolic links or to binary
files, -X<ours|theirs> has no chance of affecting the outcome.
I do not recall people talking about symbolic links but the case of
binary files has been on the wishlist for a long time, and I do not
know of anybody who is working on (or is planning to work on) it.
next prev parent reply other threads:[~2017-09-26 1:56 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
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 [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqing6cje7.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=yoh@onerussian$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox