为什么 git log --cherry-pick 不删除等效提交？答案

【问题标题】：Why is git log --cherry-pick not removing equivalent commits?为什么 git log --cherry-pick 不删除等效提交？
【发布时间】：2013-03-26 07:26:10
【问题描述】：

我一直在尝试使用

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

【问题讨论】：

这应该用 Git 2.31（2021 年第一季度）修复：stackoverflow.com/a/65946225/6309

标签： git git-log cherry-pick git-cherry-pick

【解决方案1】：

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

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

【讨论】：

每个分支上的提交 ID 确实不同。但它们可能都在不同的点被合并到两个分支中（如果有意义的话）。
Cherry-picking 总是会引入一个新的提交 id，因为父节点或时间已经改变。但是如果 master 被合并到 my-branch ，两个版本现在都存在于分支上，因此将报告樱桃挑选的版本，因为提交 id 的精确匹配优先。尝试使用git branch --contains 16cbd0e 和git branch --contains c53c7c3。我敢打赌，其中至少有一个同时显示master 和my-branch。需要考虑的一件事：如果你要合并一个分支，你可能不应该从中挑选。不仅因为这个，它还让历史变得混乱。
这仍然困扰着我。我们合并是为了保持历史的一致性，我们最终会选择樱桃，因为很难执行那种知道在工作完成时应该在哪里做的纪律。樱桃采摘最终成为不可避免的事情。错误首先得到修复，位置通常是事后才想到的。如果您除了编写我自己的工具来查看补丁 ID 之外还有其他想法，我仍在寻找一种从日志视图中删除这些重复提交的方法。
@Wivlaro 不幸的是，我看不到其他方法。几个月前我已经追踪到了这种行为，并深入研究了 Git 源代码。我没有看到让它同时过滤补丁和提交 ID 的选项。 :-(
@TechliveZheng 绝对有可能，而且我什至认为这很简单。我认为障碍将是性能障碍。这意味着您需要同时搜索补丁 ID 和提交 ID，这可能会将性能置于 Git 项目可能无法接受的区域。它不像 50% 的性能下降那么简单，因为您只会检查任何一方都不存在的提交的补丁 ID。可能值得在 Git 邮件列表中提出。

【解决方案2】：

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

这种行为现在（Git 2.11，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" 用于包含合并提交作为候选与其他提交匹配，导致大量时间浪费。补丁 ID 生成逻辑已更新为忽略合并到避免浪费。

[...] 我们可能会花费大量额外的时间来计算这些合并差异。
在启发这个补丁的案例中，“git format-patch --cherry-pick”从超过 3 分钟缩短到不到 3 秒。

而with Git 2.31 (Q1 2021)，它是固定的：当多个具有相同补丁 ID 的提交出现在一侧时，“git log --cherry-pick A...B”^(man) 现在确实会排除它们具有相同补丁 ID 的提交出现在另一侧。

【讨论】：

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

`patch-ids`：拒绝计算 `patch-id` 进行合并提交