为什么cherry pick在提交未触及的行中显示冲突？

Question

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

后来，我尝试从分支分支中挑选一个非常简单的提交：

git cherry-pick ab797f0c

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

我尝试了 EGit，它显示了一条注释：“EGit 使用交互式 rebase 机制进行樱桃采摘，这与常规 Git 不同......”但我遇到了相同或类似的冲突！

我试过：

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 类似的冲突。

更新2：

看来我的简化示例存储库仅显示了 EGit 的问题。git 在预期的选定提交技巧之一中显示了冲突。

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

Answer 1

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

diff 技巧可能在这种情况下有效，甚至可能正确地完成了您想要的操作，但并非在所有情况下都有效。 git cherry-pick正在采取更务实的方法，提醒您该领域的变化，以便您决定如何整合这些变化。根据情况，不同的比较算法可以减少冲突（或使冲突更有意义）。您可以通过使用-X选项（例如-Xpatience使用耐心算法）来完成此操作。但在这种具体情况下，这些都不起作用。

综上所述，如果您发现自己经常挑选提交并最终经常遇到相同的冲突，那么rerere可能是您的朋友。您可以使用 全局启用它git config --global rerere.enabled。它会记录您所做的决议，如果您再次遇到它，它会自动应用它。樱桃选择仍然会停止应用之前的解决方案，但这是一个快速审查，--continue可以确保它做了正确的事情。