I'm not sure this is entirely fair. I've run into a fair number of merges where git couldn't resolve the conflict but meld or p4merge was able to do it triviall

I'm not sure this is entirely fair. I've run into a fair number of merges where git couldn't resolve the conflict but meld or p4merge was able to do it trivially. If git were able to better deal with these, I don't think anyone would question it. I suspect over time that git probably has gotten smarter with merges. I surveyed a fair number of DVCS systems in the run-up to git. I'm hardly an expert, but gracefully dealing with merge conflicts was indeed something system authors were investigating. Darcs went so far as to have a formal theory of patch management [1], which guaranteed never to have a conflict (unfortunately, running the proof engine could take unduly long and in some cases, may never complete). Anyway, I think it's a tricky balance to strike. You're right that if the SCM resolves the conflict improperly and introduces a logic error, that's really tedious to track down. However, I've encountered far too many cases of bad rebases or merges resolved incorrectly by humans as well. Sometimes it's a small change the developer didn't pick up in line that was edited by both. Sometimes it was a lack of understanding of incoming changes. Sometimes it was just a battle lost to the merge tool (e.g., seeing "<<<<<<<" in source files). In all those situations, I long for a smarter merge tool. [1] -- https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theo...