How well do various revision tools handle merge conflicts?

Flashback: Discussion of merging<p>2009: Git: Bram Cohen vs Linus Torvalds <a href="http://news.ycombinator.com/item?id=505876" rel="nofollow">http://news.ycombinator.com/item?id=505876</a><p>which refers to<p>2007: A look back: Bram Cohen vs Linus Torvalds <a href="http://www.wincent.com/a/about/wincent/weblog/archives/2007/07/a_look_back_bra.php" rel="nofollow">http://www.wincent.com/a/about/wincent/weblog/archives/2007/...</a><p>which refers to<p>2005: Re: Merge with git-pasky II. <a href="http://www.gelato.unsw.edu.au/archives/git/0504/2153.html" rel="nofollow">http://www.gelato.unsw.edu.au/archives/git/0504/2153.html</a><p>Where Linus says:<p>For example, it seems like most SCM people think that merging is about getting the end result of two conflicting patches right.<p>In my opinion, that's the _least_ important part of a merge. Maybe the kernel is very unusual in this, but basically true _conflicts_ are not only rare, but they tend to be things you want a human to look at regardless.<p>The important part of a merge is not how it handles conflicts (which need to be verified by a human anyway if they are at all interesting), but that it should meld the history together right so that you have a new solid base for future merges.<p>In other words, the important part is the _trivial_ part: the naming of the parents, and keeping track of their relationship. Not the clashes.<p>For example, CVS gets this part totally wrong. Sure, it can merge the contents, but it totally ignores the important part, so once you've done a merge, you're pretty much up shit creek wrt any subsequent merges in any other direction. All the other CVS problems pale in comparison. Renames? Just a detail.<p>And it looks like 99% of SCM people seem to think that the solution to that is to be more clever about content merges. Which misses the point entirely.<p>Don't get me wrong: content merges are nice, but they are _gravy_. They are not important. You can do them manually if you have to. What's important is that once you _have_ done them (manually or automatically), the system had better be able to go on, knowing that they've been done.

Some of the more complicated merges, e.g. "adjacent lines" scare me. The comment says "They clearly don't conflict since they don't modify the same lines." And while that seems obvious for humans reading the given test case, it seems easy enough to construct a situation where that is not the case due to, for instance, a function call spread out over multiple lines.<p>Sadly these merges require a fair amount of language-specific knowledge. That doesn't have to be something that we can't ever expect merge tools to do, but one has to be realistic.

I thought the three way merge tool was independent of the source control system. I'm pretty sure that's true for the four systems I've used: hg, tfs, perforce, and the horrible horrible SLM. I can say however that SLM's default three way merge just seemed to always do the right thing.<p>Tools for managing real conflicts seem more interesting. Most conflict resolution tools seem to 'help' in a way that leaves me completely baffled. They automate the creation of unintentional edits rather than helping you understand the history of the changes that lead to the conflict, and tracking and reversibility of what you are doing during merge.<p>I've resorted to temporarily overlaying another source control system to track dealing with resolving large complicated merge conflicts.

See <a href="http://www.guiffy.com/SureMergeWP.html" rel="nofollow">http://www.guiffy.com/SureMergeWP.html</a> for another merge test suite with some background material. A year ago i tried a few of them in various diff-tools, none passed all of the tests, including guiffy even though they claim to in the article. Some of the tests can also be considered objective or non-resolvable but it still an eye opener to see how poor the merge tools really are.<p>Btw, i thought merge conflict handling was a feature of the diff tool, not the scm?

I'd like to see TFS in there. Mostly out of resentment.