Why Mercurial doesn't need "recursive merge strategy"?

Question

AFAIK git's default merge strategy is "recursive" which means when more than one "common ancestor" ends up being a "good candidate", git will merge them and create a new "virtual common ancestor" for the contributors. It basically helps solving situations where files were already merged and it avoids merging them again or coming up with incorrect merge contributors.

My question is: if Mercurial doesn't use "recursive", how does it handle the same situation?

Thanks

Answer 1

Most version control system do not know how to handle a situation where there is multiple base versions for a merge. The math merge equation is

Result = Destination + SumOf(I=1-N)(Base(I) - Source(I))

In most cases N=1 and you got a classic merge with source, destination and base versions which a typical 3-way merge tool can handle. Although many source control systems do not have even in this simple case a correct algorithm for finding the Base version. To do so you need to trace back through version tree going up the merge arrows, until you meet at a common ancestor. But sometimes the common ancestor is too far, not fitting the equation above for N=1 and in that case you need to find multiple common ancestors for multiple partial merges.

Example would be a case where a branch is merged down and up multiple times, then we try to cross merge the changes from this branch to another branch. In such case the N > 1, but lower than the number of merge downs on the source branch.

This is one of the hardest thing to do in branch merging and I don't know a source control system that actually does it correctly.