Git实施了一个recursive 3-way merge策略solves problems with criss-crossing histories，但这个策略没有解决什么问题？
到目前为止，我发现的最佳帐户位于old revctrl wiki：
递归三向合并通常会提供正确的答案，但是有一些边缘情况。例如，冲突标记可能被错误地匹配，因为它们没有为合并算法赋予任何特殊的语义含义，并且简单地被视为行。特别是，存在（有些复杂）两个无关冲突的冲突标记相互匹配的情况，即使它们的内容部分完全不相关。
此外，递归合并可以执行一些与SimpleWeaveMerge相同的无效合并，这将在下面描述，尽管它在这些情况下的确切行为高度依赖于3路合并算法的细节，但是目前尚不清楚调整3向合并算法是否更加保守地显示冲突会使这些问题消失。基本上，包括冲突在内就是创造一种编织，并且引入了编织所带来的问题。
最后，递归三向合并具有ImplicitUndo的所有固有问题。特别是，将多个合并得很干净的东西合并在一起有时会根据合并发生的顺序给出不同的答案。实际上，在一个永无止境的纵横交错的案例中，有可能触发一个值，直到时间结束，而不会发生任何一次不洁合并。这是一个非常基本的问题，修复它需要首先决定在这种情况下想要发生什么，因为什么是适当的行为尚不清楚。
然而，这些问题含糊不清。递归3向合并中断的具体情况是什么，以及它以什么方式中断？
任何人都可以显示一些它搞砸的版本控制历史吗？
（我不是在询问diff算法中的问题，例如理解源代码语义或解决冲突。让我们假设用户很乐意解决冲突并使用天真的字符串差异。）
答案 0 :(得分：1)
Reddit user / u / PascaleDaVinci提出了一个问题here：
A / \ B B | A程序员在两个分支中引入了一个变化，然后在一侧恢复它。三方合并会在没有冲突的情况下重新引入它，但不清楚这是否是程序员的意图，因为她拒绝了一方的改变，而是将其保留在另一方。因为三向合并忽略了修订之间的变化历史，所以他们没有看到模糊的程序员意图，因此无法识别这种歧义。
根据您对合并算法应该做什么的解释，您可能会将此称为问题。
答案 1 :(得分：-1)
（这不是问题的完整答案，但它可能有助于得出答案。）
事实证明，版本DAG中的纵横交错问题类似于semilattices数学领域中order theory的定义，用于CRDT研究以定义数据结构可以合并而无错误的版本历史记录：
总结：CRDT需要半格。半格需要每对条目具有唯一的最低上限。版本控制中的3向合并还要求存在唯一的最小共同祖先，并且如果没有，则具有创建一个算法的算法。
结论：CRDT研究有可能证明，如果版本图形成半格，则可以完美合并，如果是这样，那么证明可以推广到证明递归3向合并是也很完美。一个好的领导可能是分析algebraic operators of a semilattice的有用性，它只有在有一个独特的最不共同的祖先时才会有用。这些运算符可能是合并所必需的 - 如果是这样，那么就必须有一个最不共同的祖先。