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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html