我一直在尝试使用
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怎么不把这些当作重复的?
在做了这些挑选之后，你把master合并到你的分支了吗?--cherry-pick首先通过匹配提交id工作，然后如果失败，则查找补丁id。如果您已经将master合并到分支中，那么您现在就拥有了分支上的实际提交和精心挑选的版本。因此，它将找到提交id，然后继续报告精心挑选的版本。
我经常想git是否应该总是检查这两个，但这可能会对性能造成很大的影响。
我经常想git是否应该总是检查这两个，但这可能会对性能造成相当大的影响。
该行为现在(Git 2.11, 2016年第四季度)比以前更快。
参见Jeff King (peff)的commit 7c81040 (12 Sep 2016)和commit 5a29cbc (09 Sep 2016)。
帮助:Johannes Schindelin (dscho)。
(由juno C Hamano—gitster—在commit f0a84de, 2016年9月21日合并)
patch-ids:拒绝计算合并提交的patch-id
"
git log --cherry-pick";用于将合并提交作为候选提交与其他提交相匹配，导致大量的时间浪费。补丁id生成逻辑已更新为忽略合并到避免浪费。
[…我们可能会花很多额外的时间来计算这些合并差异。
在启发这个贴片的案例中，一个"git format-patch --cherry-pick";从超过3分钟缩短到不到3秒。
并且在Git 2.31 (Q1 2021)中，它是固定的:当多个具有相同补丁ID的提交出现在一侧时，"git log --cherry-pick A...B "(man)现在在另一侧出现具有相同补丁ID的提交时将它们全部排除。