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



我想获取两个给定标签之间的更改,命令是:

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

但它非常慢。

我分别逐个测试参数。只有当使用--cherry-pick时,git 日志才非常慢。

为什么?有人可以帮助我吗?

--cherry-pick
当提交集受到对称差异的限制时,省略任何引入与"另一端"上的另一个提交相同的更改的提交。

例如,如果你有两个分支,A 和 B,则仅在它们的一侧列出所有提交的常用方法是使用 --left-right(请参阅下面的示例 --左-右选项的说明)。但是,它显示了从另一个分支中挑选的提交(例如,"b上的第三个"可能是 从分支 A 中挑选)。使用此选项,此类提交对将从输出中排除。

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

我一直在使用

git log tag1 --not tag2

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

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

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

git gc

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

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

参见:樱桃采摘很慢

对于合并递归,我们总是希望计算成对 在每一侧和祖先之间重命名。所以差异到 挑选目的地总是一个昂贵的 O(# of 源和目标之间的更改)操作。

如果没有重命名,您可以在实际合并时做得更好 三向树步道。例如,您看到某个子树位于树 A 中oursancestor树,但在theirs树B.所以你没有 必须进一步下降,只能说"拿走他们的"(好吧,你有 降序theirs获取值)。但我希望它会得到更多 与索引的交互变得复杂(并且可能不是 无论如何,由于重命名问题,值得花很多精力)。

-佩夫

相关内容

  • 没有找到相关文章

最新更新