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
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.
The original author of Mercurial wrote about why he didn't use recursive merge strategy (link): Basically the answer is:
For the cases where ancestor ambiguity is the most interesting [...] recursive merges don't help at all. So I don't think they warrant the extra complexity
But the full answer is really interesting to read so I encourage you to do so. I'll just copy it here in case it disappear:
> Does Mercurial supports recursive merge strategy like git? It is used
> in situation when
> merge has two "common" ancestors (also know as criss-cross merge)
>
> According to http://codicesoftware.blogspot.com/2011/09/merge-recursive-strategy.html
> Mercurial
> does not support it but I wanted to ask to make sure that nothing has changed.
Indeed. But you shouldn't judge the situation from this blog post as
it's not coherent.
In particular, the example given under "Why merge recursive is better –
a step by step example" doesn't appear to be a recursive merge situation
at all! Notice the key difference in topology as compared with the
initial diagrams: no criss-crossing merges leading up to the merge. Some
kind of bait and switch happening here.
In the example itself, Git will choose the same (single) ancestor in a
merge between nodes 5 and 4 as Mercurial would, 0. And thus both give
the result 'bcdE'. So we've learned precisely nothing about recursive
merge and how it compares to Mercurial from this example. The claim that
Mercurial chooses the "deepest" ancestor: also wrong and nonsensical.
The deepest ancestor is the root.
This seems to be yet another instance of "Git is incomprehensible,
therefore Git is magic, therefore Git magically works better" logic at
work.
Let's _actually_ work his original example diagram which has the
criss-crossing merges (which I guess he copied from someone who knew
what they were talking about). I'm going to ignore the blogger's
nonsensical use of arrows that point the wrong way for branch merges and
thus add cycles into the "directed acyclic graph". Here history flows
from left to right, thus the edges are right to left:
a---b-d-f---?
\ \ / /
\ X /
\ / \ /
c-e-g
Let's make up a simple set of changes to go with that picture. Again,
think of each character as a line:
a = "a"
b = "a1"
c = "1a"
d = "a2"
e = "2a"
f = merge of d and c = "1a2"
g = merge of e and b = "2a1"
When we merge f and g, our greatest common ancestor is either b or c. So
we've got the following cases:
b: we had a1 originally, and are looking at 1a2 and 2a1. So we have a
conflict at the start, but can simply choose 2 for the end as only one
side touched the end.
c: we had 1a originally, and are looking at 1a2 and 2a1. So we have a
conflict at the end, but can simply choose 2 for the start as only one
side touched the start.
Mercurial will choose whichever one of these it finds first, so we have
one conflict to resolve. It definitely does not choose 'a' as the
ancestor, which would give two conflicts.
Now what a recursive merge would do would be merging b and c first,
giving us "1a1". So now when we merge, we don't have conflicts at the
front or the back.
So yay, in this simplest of examples, it's a win. But cases where this
actually matters aren't terribly common (let's call it 1% to be
generous) and cases where it actually automatically solves the problem
for you seamlessly are actually less than half of THOSE cases.
Instead, if you've got conflicts in your recursive merge, now you've
made the whole situation more confusing. Take your blog post as Exhibit
A that most people don't understand recursive merge at all which means
when a merge goes wrong, not only do you need an expert to diagnose it,
you need an expert to tell you who the 'experts' even are.
We talk about recursive merge occasionally. But as it happens, for the
cases where ancestor ambiguity is the most interesting (merging with
backouts, exec bit changes), recursive merges don't help at all. So I
don't think they warrant the extra complexity.
© 2022 - 2024 — McMap. All rights reserved.