为什么git log --cherry-pick这么慢？

Question

我想要得到两个给定标签之间的变化，命令是：

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

但它的速度非常慢。

我逐一测试参数。只有在使用--cherry-pick时，git日志才会非常慢。

为什么？有谁能帮我吗？

Answer 1

--选樱桃

当该组提交受到对称差异的限制时，忽略引入与“另一端”上的另一提交相同的更改的任何提交。

例如，如果您有两个分支，A和B，通常只在其中一侧列出所有提交的方法是使用--left-right (参见下面的--left-right选项描述中的示例)。然而，它显示了从另一个分支中精挑细选的提交(例如，“3onb”可能是从分支A中精选的)。使用此选项，将从输出中排除此类提交对。

它必须比较所有的提交，寻找相似之处--与根本不做任何比较相比，这将是一个非常慢的操作。

Answer 2

我一直在用

git log tag1 --not tag2

这让我所有的提交都在tag1上，而不是tag2上。同样适用于分支和标签。

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(源和目标之间的更改数量)操作。

在没有重命名的情况下，使用三向树遍历可以在实际的合并中做得更好。例如，您可以看到一些子树在ours和ancestor树中位于树A，但在theirs中位于树B。因此，您不必进一步下降，只需说“接受他们的”(好吧，您必须下降theirs才能获得值)。但我预计与索引的交互会变得更加复杂(无论如何，由于重命名问题，可能不值得花费太多精力)。

-Peff