Jenkins git插件--有时候太慢了

Question

以下内容摘自Jenkins日志：

00:00:03.135  > git fetch --tags --progress git@github.com:some_org/some_repo.git +refs/heads/*:refs/remotes/origin/*
00:03:49.659  > git rev-parse origin/master^{commit} # timeout=10

我不明白为什么会发生这种超时，因为在同一台机器上运行git fetch，使用相同的用户，大约需要5到10秒。

我使用的是Git的最新版本(2.1.2)和最新版本的gitplugin。

有什么想法？

Answer 1

至少在我们的例子中，问题是git版本。我们从1.9升级到2.1.2，问题得到了解决。当我第一次发这个问题的时候，我有错误的印象，以为升级已经开始了。

Answer 2

注:使用git 2.2+ (2014年11月)，Git获取速度应该会再次提高。

参见提交cbe7333，由Jeff (peff)所著：

参考文献:加速is_refname_available

我们的文件系统ref存储不允许D/F (目录/文件)冲突；因此，如果"refs/heads/a/b“存在，则不允许"refs/heads/a”存在(反之亦然)。 这对于松散引用自然会出现，其中文件系统强制执行该条件。但是对于裁判来说，我们必须自己做检查。 我们这样做的方法是遍历整个打包引用名称空间，并检查每个名称是否会产生冲突。如果您有大量的参考文献，这是非常低效率的，因为您最终会与ref树中的一些不感兴趣的部分进行大量的比较(例如，我们知道在上面的示例中，所有的"refs/tags“都是无趣的，但是我们检查了其中的每个条目)。 相反，让我们利用这样一个事实:我们将打包的引用存储为ref_entry结构的trie。 我们可以在遍历树的过程中找到建议的refname的每个组件，检查D/F冲突。对于深度refname N (即上面示例中的4)，我们只需访问N节点即可。每次访问时，我们都可以在该级别上对M名称进行二进制搜索，以了解O(N lg M)的总体复杂性。(当然，每个级别的“M”都是不同的，但我们可以以最坏的"M“作为界)。 在一个病理性案例中，用850万个参考文献将30,000名新的裁判带到一个存储库中，这使运行"git“的时间从几十分钟降到了~30秒。 这也有助于更小的情况，在这种情况下，我们检查松散引用(在重命名引用时这样做)，因为我们可能避免对无关的松散目录进行磁盘访问。 请注意，我们添加的测试乍一看似乎与t3210中已经存在的测试是多余的。但是，早期的测试并不健壮；它们是在打开重触发器的情况下运行的，这意味着我们实际上根本没有测试is_refname_available！ 操作仍将失败，因为重发将在文件系统中发生D/F冲突。 要获得真正的测试，我们必须关闭重新触发器(但我们不想对整个脚本这样做，因为打开它们的目的是要覆盖其他一些情况)。