On Mon, Jul 6, 2009 at 3:33 AM, Linus Torvalds<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: [...] > > 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 > Indeed it seems I had a wrong image of how a conflict file should look. In the light of what you've told me now, everything makes sense :) Thank you very much for taking your time to explain these things! Cheers, Stefan Bucur -- 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