为什么Mercurial不需要“递归合并策略”？

Question

AFAIK git的默认合并策略是“递归”，这意味着当多个“共同祖先”最终成为“好的候选者”时，git将合并它们并为贡献者创建一个新的“虚拟共同祖先”。它基本上有助于解决文件已经合并的情况，并避免再次合并它们或提出不正确的合并贡献者。

我的问题是：如果Mercurial不使用“递归”，它如何处理相同的情况？

谢谢

Answer 1

大多数版本控制系统不知道如何处理合并有多个基本版本的情况。数学合并方程是

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

在大多数情况下，N = 1并且您获得了源，目标和基本版本的经典合并，这是典型的3向合并工具可以处理的。尽管许多源控制系统甚至在这个简单的情况下也没有找到基本版本的正确算法。要做到这一点，你需要追溯到合并箭头的版本树，直到你遇到一个共同的祖先。但有时共同的祖先太过分了，不适合N = 1的上述等式，在这种情况下，你需要为多个部分合并找到多个共同的祖先。

示例将是分支向下合并多次的情况，然后我们尝试将来自此分支的更改交叉合并到另一个分支。在这种情况下，N> 1，但低于源分支上的合并数量。

这是分支合并中最难做的事情之一，我不知道实际上正确执行它的源控制系统。

Answer 2

Mercurial的原作者写了为什么他没有使用递归合并策略（link）：基本上答案是：

对于祖先歧义是最有趣的[...]递归合并的情况根本没有帮助。所以我不认为它们需要额外的复杂性

但是完整的answer读起来非常有趣，所以我鼓励你这样做。我会在这里复制它，以防它消失：

> 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.