为什么git log --cherry-pick没有删除等效的提交？

Question

我一直在尝试使用

git log --no-merges --cherry-pick --right-only master...my-branch

生成my-branch中的提交列表，但不是master中的提交列表（根据git-log文档）。但是，列表中仍有许多等效的提交。如果我展示它们及其补丁，除了提交ID之外没有区别。

git show 16cbd0e47406a4f7acbd6dc13f02d74d0b6a7621 >patcha
git show c53c7c32dcd84bfa7096a50b27738458e84536d5 >patchb

diff patcha patchb
1c1
< commit 16cbd0e47406a4f7acbd6dc13f02d74d0b6a7621
---
> commit c53c7c32dcd84bfa7096a50b27738458e84536d5

即使git patch-id显示它们是等效的：

git show c53c7c32dcd84bfa7096a50b27738458e84536d5 | git patch-id
2b5504fb9a8622b4326195d88c7a20f29701e62b c53c7c32dcd84bfa7096a50b27738458e84536d5
git show 16cbd0e47406a4f7acbd6dc13f02d74d0b6a7621 | git patch-id
2b5504fb9a8622b4326195d88c7a20f29701e62b 16cbd0e47406a4f7acbd6dc13f02d74d0b6a7621

git log --cherry-pick如何不重复这些？

Answer 1

自从做樱桃选择以来，您是否已将master合并到您的分支中？ --cherry-pick首先匹配提交ID，然后如果失败，则查找补丁ID。如果你已经将master合并到你的分支中，那么你现在将在你的分支和樱桃挑选版本上实际提交。所以它会找到提交ID，然后继续报告樱桃挑选的版本。

我经常想知道git是否应该始终检查两者，但这可能是一个相当大的性能影响。

Answer 2

  

我经常想知道git是否应该始终检查两者，但这可能是一个相当大的性能影响。

现在这种行为（Git 2.11，Q4 2016）比以前更快。

commit 7c81040（2016年9月12日）和commit 5a29cbc（2016年9月9日）Jeff King (peff)。 帮助：Johannes Schindelin (dscho)。
^{（由Junio C Hamano -- gitster --合并于commit f0a84de，2016年9月21日）}

  

patch-ids：拒绝为合并提交计算patch-id

     

“git log --cherry-pick”曾用于包含合并提交作为候选人   与其他提交相匹配，导致大量浪费时间。   patch-id生成逻辑已更新为忽略合并   避免浪费。

     

[...]我们可能会花费大量额外的时间来计算这些合并差异   在启发此补丁的情况下，“git format-patch --cherry-pick”从3分钟以上下降到不到3秒。