Re: -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 26, 2017, 01:56 UTC
Message-ID: <xmqqing6cje7.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170925143040.4qgofxcdahal46r7@hopa.kiewit.dartmouth.edu>

Yaroslav Halchenko <yoh@onerussian.com> writes:

Show 8 quoted lines

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