为什么樱桃选择会在未提交的行中显示冲突？

Question

当我第一次阅读git cherry-pick时，我认为它是在新提交中将提交引入的更改应用为HEAD的补丁。我的前几个用法符合这种看法。

后来，我试图从一个不同的分支中选择一个非常简单的提交：

git cherry-pick ab797f0c

令我惊讶的是，我在提交未触及的行中遇到了几个冲突！提交非常简单，在一个文件中更改了2行。

我尝试了EGit，其中显示了一个注释：＆＃34; EGit使用交互式rebase机制进行樱桃采摘，这与常规Git不同......＆＃34;但我得到了相同或类似的冲突！

我试过了：

git diff ab797f0c^ ab797f0c |patch -p1

完美无缺，处理了大块偏移。

为什么git / EGit在选择patch时可以轻松应用的提交时遇到问题？ 樱桃选择如何在git中真正起作用，它在EGit中有何不同？

更新

根据Andrew的建议，我试图将问题简化为一个简单的存储库。这是：https://github.com/alhashash/cherry-test

我在test并尝试挑选Cherry。 git cherry-pick Cherry产生了许多与提交无关的冲突，而git diff Cherry^ Cherry |patch -p1工作正常！

EGit提供与git类似的冲突。

UPDATE2：

看来我的简化示例存储库仅显示EGit的问题。 git在所选择的提交预期之一中显示出一个冲突，这是预期的。

我会尝试在简单的存储库中复制git的问题。我遇到的问题是oddo OCB forked repo我在提交fb978c60并试图挑选ab797f0

Answer 1

这是因为git cherry-pick正在底层执行3向合并，并且提交C正在修改与提交B相同的区域。差异技术有效，因为默认情况下补丁最多会忽略2行上下文，git cherry-pick没有。如果您再次使用patch -p1 -F0，补丁也将无法应用它。

在这种情况下，差异技巧可能有效，甚至可能正确地完成了你想要的东西，但并非在所有情况下都如此。 git cherry-pick正在采取更务实的方法，并提醒您区域的变化，以便您决定如何将这些变更整合在一起。根据具体情况，不同的差异算法可以减少冲突（或使它们更有意义）。您可以使用-X选项（例如-Xpatience来使用耐心算法）来执行此操作。但这一切都不适用于这种特殊情况。

所有这一切都说，如果你发现你经常采摘提交并经常遇到相同的冲突，rerere可能是你的朋友。您可以使用git config --global rerere.enabled全局启用它。它将记录您所做的分辨率，如果再次遇到它，它将自动应用它。樱桃挑选仍然会在之前的分辨率应用中停止，但它是一个快速回顾和--continue远，以确保它做了正确的事情。