Question

给定存储库结构：

o-o-o-o-o-<several hundreds of commits>-o-o-C-o-o master
                                           /
                                          c (files moved to a subdirectory)
                                         /
a-a-a-<several tens of commits>-a-a-a-a-A-b-b-b-b tools

这是一个多根的存储库，“master”行上的所有提交都表明第一个父级位于该分支上，同样，“工具”上的所有提交都有他们的第一个父级跟随工具分支

提交'c'是为了让合并提交'C'变得微不足道，以便布局与master匹配。

为什么'git cherry -v master工具需要这么长时间？

编辑：

我的本地测试指的是错误的分支（我使用了错误的名称），然而，仍然认为git cherry非常慢。

Answer 1

git cherry 命令从fork-point开始比较

$ git cherry -v tools master

           __*__*__*__*__> <tools>
          /
fork-point
          \__+__+__-__+__+__-__+__> <master>

我们可以通过向<limit>指定 git cherry 参数来避免这种情况，如下所示

$ git cherry -v tools master <limit>

           __*__*__*__*__> <tools>
          /
fork-point
          \__*__*__<limit>__-__+__> <master>

现在所有沿着分支的提交都被忽略了;从而使git cherry命令能够更快地完成。

为什么？

通过man page of git cherry我们可以注意到以下内容：

因为git cherry比较了变更集而不是提交ID（sha1），所以你可以使用git cherry来查明你在本地提交的提交是否已经在不同的提交id下应用。例如，如果您通过电子邮件提供补丁而不是直接推送或提取提交，则会发生这种情况。

基本上这意味着 git cherry不仅仅是比较commit-id的哈希值，而是整个changesets / diffs / commits 。这是看似花费大量时间的主要原因（与其他类似的git命令相比）。

为什么git cherry如此惊人地缓慢？

1 个答案:

为什么？