23

我一直在尝试使用

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将这些作为重复项？

4

2 回答 2

6

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

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

于 2013-04-04T09:44:31.110 回答
1

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

这种行为现在（Git 2.11，2016 年第四季度）比以前更快。

请参阅Jeff King ( )的提交7c81040 （ 2016 年 9 月 12 日）和提交 5a29cbc（2016 年 9 月 9 日） 。 帮助者：Johannes Schindelin ( )。（由Junio C Hamano 合并——在提交 f0a84de中，2016 年 9 月 21 日）peff
dscho
gitster

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 的提交时将它们全部排除边。

于 2016-09-26T07:20:38.417 回答