I've used many different version control systems. Git is, by far, the best at merging and avoiding conflicts to start with. I believe it's because it can often work from the basis of a common ancestor commit, so it's able to perform three-way merges instead of two-way merges.
Wait, avoiding 3-way merges and instead only allowing 2-way merges has been on my list of "advantages of Mercurial that are sadly lost to git" list for a while. Can you expand on what you're saying?
Three-way merge might not be the correct term. I mean it as in the three versions being "original", "version-a", and "version-b". Original is the most recent common ancestor of version-a and version-b. So the system can generate clean diffs based on that original version during the merge.
I've seen other systems essentially say, "Oops both versions modified this file... Good luck!" It didn't matter that the modifications were to very different parts of the file. I've never seen that in Git. Any merge conflict I've gotten in Git has been a true potential conflict, even if the resolution is straight-forward from my perspective.
Ah, that's a standard merge but a 3-way diff. Many DVCSs have that (including Mercurial).
A 3 way merge would have "original", "version a", "version b", and "version c", where "original" is the common ancestor of a, b and c. Mercurial disallows merges like this, but git supports them. I have no idea why git allows it.
But yes, older VCSs ignored the "original" concept, which meant diff tools could just pop up "a" and "b". Which is just a way worse idea than including the original as well.
