Git merge 策略 : spaces make default shows no conflict and bring unexpected results

Question

经过多次尝试，我得到了这个简单的测试用例场景:

a --> b --> c --   (master)
 \              \
  --> d --> b' --> e   (branch)

地点:

• b' 是 b
的精选
• e 是来自 master 的 merge 。

b' 是在 c 之后完成的，并且 c 修改了与 b 相同的文件( d 可能无关紧要)。

e 很容易看起来非常出乎意料。

假设他们都在处理同一个文件“foobar.txt”。这是文件在每次提交中的样子:

// ----------- a
foo

delme

bar

// ----------- b
foo

delme

new

bar

// ----------- c
foo

new

bar

// ----------- b'
foo

delme

new

bar

// ------------ e
foo

new

new

bar

现在，这是我刚才用这个精确设置进行的简短测试。

如果您删除所有 spaces在那里，没有这样的问题。正如我所料，Merge 只会指责冲突。但我不认为对空格使用任何 -X 设置是我们在这里寻找的......或者是吗？

与此同时，在我的生产代码中，这也是我开始研究这一切的原因，它几乎没有那么多空白，我看到 e 看起来像这样:

// ----------- e
foo

delme

new

bar

merge 发生的一切从不指责任何冲突!

如果 git 在这里做任何它的巫术魔法自动 merge ，这就是我期望的样子:

// ----------- e
foo

new

bar

但这也不会发生。

---

作为一个免责声明...

我也试过reading the f manual ，但是 merge 策略下的太多点我实在是看不懂。此外，它并没有真正说明 resolve 策略在幕后做了什么，例如:

It tries to carefully detect criss-cross merge ambiguities and is considered generally safe and fast.

什么都没说。

关于默认 recursive 的文本更大，但我也无法从中提取足够的信息:

This has been reported to result in fewer merge conflicts without causing mis-merges by tests done on actual merge commits taken from Linux 2.6 kernel development history.

报告？所以我们进行了 1 个非常繁重的单元测试，并根据一些报告假设它没问题？

嗯，这对我来说太模糊了。

---

我想我一定做错了什么!那么，我怎样才能做对呢？

我需要做什么才能无后顾之忧地重新开始 merge ？

Answer 1

基本问题是，对于在每种情况下都做正确事情的正确自动 merge 意味着什么，没有正式的模型。事实上，对于不同的用例，“正确的事情”可能会以 merge 算法不知道的方式有所不同。已经进行了多种尝试来提出一个始终做正确事情的单一、正确的 merge 算法(各种 Monotone merge 策略、Codeville、Precise Codeville、Darcs 等等)，但它们都以某种方式失败了真实世界的用例。

因此，对于真实世界的 merge 算法，“它在具有大量 merge 的真实代码库上运行良好”大约是您将能够做的最好的事情。这意味着您永远不应该盲目地相信干净的自动 merge 的结果；虽然它可能已经完全 merge 而没有冲突，但它可能没有完全按照您的预期进行。您仍然需要查看 merge 做了什么，并测试结果。

我的一般方法是尝试几个不同的 merge 选项，就像您所做的那样，看看其中一个是否产生正确的 merge 。如果这不能使您获得正确的 merge (或产生您可以解决的适当冲突的 merge )，那么您应该执行 git merge --no-commit，并修复在提交之前酌情 merge 。