同时获取多个Git远程仓库

Question

在git中，是否可以并行获取多个远程仓库？

下面的操作是否会与仓库中的git文件锁冲突？

git config gc.auto 0
git remote |xargs --max-procs=4 -n 1 git fetch
git gc

我对几个代码库进行了小规模的测试，发现当所有代码库之间没有关联时，该并行拉取命令似乎可以正常工作。

如果有明显的技术原因解释为何上述并行拉取命令不能工作，希望能得到反馈。

子模块支持并行拉取，但在使用 git-subtree 方法时，采用并行拉取会更好。

类似问题：如何并行拉取多个远程 Git 仓库？

- JohannPetr

Answer 1

看起来对我而言，这个功能开箱即用

git fetch -j 8   

使用Git 2.33.1。 -j 开关是 --jobs 的简写。我记得之前找过这个开关，但今天才知道，这个开关可能非常新。

对于一个具有四个GitHub远程存储库的存储库的一些时间：

$ \time git fetch --all
Fetching origin
Fetching foo
Fetching bar
Fetching baz
        6.40 real         1.28 user         0.21 sys
$ \time git fetch --all -j 8
Fetching origin
Fetching foo
Fetching bar
Fetching baz
        2.06 real         1.30 user         0.16 sys

- krlmlr

---

请告知其他人为什么开关是“-j”。因为这在手册中有说明：“-j” / “--jobs = <n>”表示用于所有形式的提取的并行子进程数。 - MS Berends

你所做的不是并行的。根据文档：如果指定了--multiple选项，则会并行获取不同的远程。(...)通常，递归并行和多远程获取速度更快。默认情况下，获取是顺序执行的，而不是并行执行的。 https://git-scm.com/docs/git-fetch - MS Berends

添加了详细选项和时间记录。 - krlmlr

Answer 2

答案实际上可能是“也许”。具体来说：

git remote | xargs --max-procs=4 -n 1 git fetch

正如您所见，这在测试时实际上是有效的，但只能做到某种程度。我曾经写过一种更高级的版本（使用Python编写的所有获取过程的高级显示控制），但事实证明git fetch --progress存在一个错误，因此使用管道无法正常工作；必须使用pty。

而不会与git文件锁冲突...当所有存储库彼此无关时，它似乎可以正常工作。

这就是难点：每个获取都假定它可以获得其锁定。获取需要锁定每个远程跟踪名称，通常情况下这很好用，因为名称是分开的——远程A不会干扰远程B，因为refs/remotes/A/master和refs/remotes/B/master使用不同的锁定，但最终的重新打包可能会失败，除非您像您所做的那样禁用自动gc，然后自己运行GC（之后还应该重新启用它）。

您还可能会获取比必要更多的数据（正如我在另一个答案中指出的）。如果没有外部信息，例如，也许有一个始终应该首先获取的远程，则无法做太多事情。

- torek

Answer 3

但是最终的重新打包可能会失败，除非您像之前那样禁用自动垃圾回收，然后手动运行GC。

实际上，从Git 2.23（2019年第三季度）开始，这可能不再是必要的。

"git fetch"从一组远程仓库中获取时，学会了在最后只运行一次auto-gc。

请查看提交c3d6b70（2019年6月19日），由Nguyễn Thái Ngọc Duy (pclouds)提交。
^{（由Junio C Hamano -- gitster --在提交892d3fb中合并，2019年7月9日）}

fetch：在获取多个远程时仅运行一次'gc'

在多个远程模式下，git-fetch将为n-1个远程启动，并且最后一个远程由当前进程处理。每个进程将依次在末尾运行'gc'。

这并不是真正的问题，因为即使同时运行多个'gc --auto'，我们仍然可以正确处理它。
它确实显示了多个“在后台自动打包”的消息。
当gc实际运行时，我们可能会浪费一些资源，因为在检查锁定并将其移动到后台之前，我们仍然需要执行一些操作。

所以让我们试着避免这种情况。

无论如何，我们应该只需要在添加所有对象和引用之后运行一次'gc'。

添加一个新选项--no-auto-gc，将由这些n-1进程使用。
'gc --auto'将始终在主要获取过程中运行(*)。

(*) 即使在未来的某个时候并行获取远程，这也应该还可以，因为在此步骤之前我们应该“加入”所有这些进程。

- VonC