为什么使用git log --cherry-pick命令如此缓慢？

Question

我希望能够获取两个指定标签之间的更改内容，命令如下：

git log `Tag1...Tag2 --cherry-pick  --no-merges --right-only

但是它非常缓慢。

我逐个测试参数。只有当使用--cherry-pick时，git log才非常缓慢。

为什么？有人能帮忙解决吗？

- Bruce Li

Answer 1

--cherry-pick
当使用对称差异限制提交集时，省略任何引入与“另一侧”上的另一个提交相同更改的提交。
例如，如果您有两个分支A和B，仅列出它们之一侧的所有提交的常规方法是使用--left-right（请参见下面关于--left-right选项的描述中的示例）。但是，它显示了从其他分支中挑选的提交（例如，“b上的第3个”可能是从分支A中挑选的）。使用此选项，这些提交对将从输出中排除。
它必须比较所有提交以寻找相似之处-与根本不需要进行任何比较相比，这将是非常缓慢的操作。

- Michael

---

谢谢您的回复，没错。我看到了这个手册。然而，正如它所说，我们计划省略出现在其他分支上的更改。除此之外，我们还有其他方法吗？ - Bruce Li

如果你使用合并（merge）而不是挑选（cherry-pick），你可以避免所有这些开销。 - Michael

是的，我知道，但问题代码库不是我们的工作，我们只是获取更改以分析某些组件的质量。我们无法控制软件开发人员的行为。 - Bruce Li

有点困惑。我已经将代码库拉到本地，并在本地运行了上述命令。你的意思是什么？抱歉，我没听懂你的话。 - Bruce Li

是的，它们来自同一来源。 - Bruce Li

Answer 2

我一直在使用

git log tag1 --not tag2

这会给我所有在tag1上的提交但不在tag2上的提交，对于分支与标签也同样适用。

- Máté

Answer 3

挑选特定提交可能不太快，因为它可能会将重命名检测作为合并的一部分，这可能很耗费时间，特别是当您挑选的提交距离 HEAD 很远时。

可能是您的 git 配置中有 gc.auto = 0（git config --get gc.auto），请确认是否已启用，或者只需运行：

git gc

为了清理不必要的文件并优化本地存储库。

您还可以尝试将merge.renamelimit配置变量设置为较小的值（例如1，因为0表示没有限制）。如果这样做没有帮助，请尝试对您的git进行分析（例如使用strace或perf record git cherry-pick ...）并找到瓶颈所在。

参见：cherry-pick is slow。

对于合并递归，我们总是希望计算每个侧面和祖先之间的成对重命名。因此，到樱桃拣选目标的差异始终将是一项昂贵的O（源和目标之间的更改数）操作。

如果没有重命名，您可以在实际合并中使用三向树遍历来获得更好的效果。例如，您会发现某些子树在树A中，在ours和ancestor树中，在树B中在theirs中。因此，您不必进一步下降，只需说“采取theirs”（好吧，您必须下降theirs以获取值）。但我认为与索引的交互变得更加复杂（而且可能不值得花费太多精力，因为重命名问题）。-Peff

- kenorb