Yaroslav Halchenko <yoh@xxxxxxxxxxxxxx> 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.
