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

Question

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

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

但它很慢。

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

为什么？有人可以帮我吗？

Answer 1

--cherry-pick
当提交集受到对称差异的限制时，忽略任何引入与“另一侧”的另一个提交相同的更改的提交。

例如，如果你有两个分支，A 和 B，列出所有提交仅在其中一侧的常用方法是使用 --left-right （参见下面的 --left-right 选项描述中的示例） . 然而，它显示了从另一个分支中挑选出来的提交（例如，“b 上的第 3 个”可能是从分支 A 中挑选出来的）。使用此选项，此类提交对将从输出中排除。

它必须比较所有提交以寻找相似之处——与根本不需要进行任何比较相比，这将是一个非常缓慢的操作。

Answer 2

我一直在使用

git log tag1 --not tag2

这给了我所有在 tag1 上而不是在 tag2 上的提交。也适用于分支与标签。

Answer 3

樱桃采摘可能不会那么快，因为它可能会将重命名检测为合并的一部分，这可能会很昂贵，尤其是当您采摘远离 HEAD 的东西时。

可能是您的 git config 具有gc.auto = 0( git config --get gc.auto)，因此请仔细检查它是否已启用，或者只是运行：

git gc

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

您也可以尝试将merge.renamelimit配置变量设置为更小的值（例如 1，因为 0 表示无限制）。如果这没有帮助，请尝试分析您的 git（例如使用straceor perf record git cherry-pick ...）并找到瓶颈。

请参阅：樱桃采摘很慢

对于合并递归，我们总是希望计算每一边和祖先之间的成对重命名。因此，与樱桃挑选目的地的差异总是会是一个昂贵的 O(# of changes between source and dest) 操作。

如果不重命名，您可以通过三向树行走在实际合并中做得更好。例如，您看到某个子树位于ours和中的树 Aancestor处，但位于 中的树 B 处theirs。所以你不必进一步下降，只需说“拿走他们的”（好吧，你必须下降theirs才能得到值）。但我预计它与索引的交互会变得更加复杂（无论如何，由于重命名问题，可能不值得花费太多精力）。

-佩夫