Yaroslav Halchenko <[email protected]> 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.
