Re: Wrong file diff for merge conflict

On Mon, 6 Jul 2009, Stefan Bucur wrote:

Thank you for your suggestions for a better and more efficient merging
experience, as I'm sure they will help me from now on. However, I
think I did not make myself clear: I was not arguing the fact that the
merge result was suboptimal, but the fact that _the generated conflict
file is semantically wrong_.

Oh. 

No, you're confused about what a conflict file is.

Basically, if one would take the common (successfully merged) parts
and keep the "left" parts in the conflict sections, one would obtain
the first branch version of the file (with minor modifications).

No. This is not how conflicts work.

If you blindly do that, you'll always get the wrong answer. Why? Because 
you're ignoring the parts of the file that didn't conflict. Those will be 
_outside_ the conflict markers in all cases.

Similarly, if one would opt to keep only the "right" parts in the
conflict section, one would obtain the version found in the second
branch before merge.

Same problem. What you expect from a conflicting file is simply not true.

The fact is, a traditional rcs three-way merge (which is pretty much what 
you get with git, ignoring the fact that we have other tools in addition 
to it, and ignoring things like criss-cross merges etc) just doesn't work 
the way you seem to think it should work. You simply don't get the 
original of one side by picking one side of the conflict markers. It will 
have merged the stuff that it thought merged cleanly, and not have any 
conflict markers at all for those parts.

Of course, "what it thought merged cleanly" may not be what you want it to 
be. Sometimes you get a clean merge for things that you'd have wanted to 
conflict. And sometimes you get conflicts for stuff that you'd think is 
just silly and shouldn't have. 

There are no perfect file merge algorithms that I know of. Lots of people 
hate the diff3/merge behavior - it's by no means perfect. But so far, I've 
never seen anybody successfully advocate anything better either.

		Linus