递归三向合并算法有哪些突出问题？

Question

Git 实现了solves problems with criss-crossing histories 的recursive 3-way merge 策略，但是这个策略没有解决什么问题？

目前我发现的最好的帐户是old revctrl wiki：

递归三路合并通常提供正确的答案，但也有一些极端情况。例如，冲突标记可能会被错误地匹配，因为它们没有为合并算法赋予任何特殊的语义含义，并且被简单地视为行。特别是，有（有些复杂的）两个不相关冲突的冲突标记相互匹配的情况，即使它们的内容部分完全不相关。

此外，递归合并可以执行一些与SimpleWeaveMerge 相同的无效合并，如下所述，尽管它在这些情况下的确切作用高度依赖于 3 路合并算法的细节，但它不是不清楚将 3 路合并算法调整为更加保守地显示冲突将使此类问题消失。基本上，包括冲突就是创建一个编织，这就引入了编织的问题。

最后，递归三路合并具有ImplicitUndo的所有固有问题。特别是，将多个干净合并的事物合并在一起有时会根据合并发生的顺序给出不同的答案。事实上，在一个永无止境的纵横交错的情况下，一个值可能会一直翻转直到时间结束，而不会得到一个不干净的合并。这是一个非常基本的问题，要解决它首先需要确定在这种情况下想要发生什么，因为什么是适当的行为尚不清楚。

但是，这些问题都被模糊地表述了。递归 3 路合并中断的具体情况是什么，它以什么方式中断？

谁能展示一些它搞砸的版本控制历史？

（我不是在询问 diff 算法中的问题，例如理解源代码语义或冲突解决。假设用户很乐意解决冲突并使用简单的字符串 diff。）

Answer 1

（这不是问题的完整答案，但可能有助于得出答案。）

原来版本DAG中的交叉合并问题类似于semilattices在数学领域order theory的定义，在CRDT研究中用于定义数据结构版本历史，可以合并无误：

• CRDT 类似于版本控制系统
• 如果 DAG 不包含交叉版本，则 CRDT 半格等效于版本控制 DAG
• 3 路递归合并策略通过确保存在唯一的“最小共同祖先”即“最低上界”，将纵横交错的 DAG 转换为有效的半格。
• “最小共同祖先”（在版本控制领域）等同于“最低上界”的概念（在格序理论中）。

总结一下：CRDT 需要一个半格。半格要求每对条目都有唯一的最低上限。版本控制中的 3 路合并还要求有一个唯一的最小公共祖先，如果没有，则有一个算法来创建一个。

结论：CRDT 研究可能有一个数学证明，即如果版本图形成半格，则完美合并是可能的，如果是这样，则可以推广该证明以表明递归 3 路合并也是完美的。一个好的线索可能是分析algebraic operators of a semilattice 的有用性，它仅在存在唯一的最不共同祖先时才成立。这些运算符可能是合并所必需的——如果是这样，那么就必须有一个最小共同祖先。

Answer 2

Reddit 用户 /u/PascaleDaVinci 提出问题here：

  A
 / \
B   B
|
A

程序员在两个分支中都引入了更改，然后在一侧恢复了它。三向合并将在没有冲突的情况下重新引入它，但尚不清楚这是否是程序员的意图，因为她一方面拒绝了更改，但另一方面保留了它。由于三向合并忽略了修订之间的更改历史记录，因此它们看不到模棱两可的程序员意图，因此无法识别这种模棱两可。

根据你对合并算法应该做什么的解释，你可能会称之为问题，也可能不是。