通过快速网络连接克隆git存储库的最快方法是什么？

时间：2011-11-18 09:48:52

标签： git performance vmware git-clone

我遇到一个相对较大的git存储库，位于我本地网络上的一个老人，慢速主机上，这需要很长时间才能进行初始克隆。

ravn@bamboo:~/git$ git clone gitosis@gitbox:git00
Initialized empty Git repository in /home/ravn/git/git00/.git/
remote: Counting objects: 89973, done.
remote: Compressing objects: 100% (26745/26745), done.
remote: Total 89973 (delta 50970), reused 85013 (delta 47798)
Receiving objects: 100% (89973/89973), 349.86 MiB | 2.25 MiB/s, done.
Resolving deltas: 100% (50970/50970), done.
Checking out files: 100% (11722/11722), done.
ravn@bamboo:~/git$

gitosis中没有git特定的配置更改。

有没有办法将接收位加速到网络的能力？

编辑：我需要新的存储库与上游存储库正确连接。根据我的理解，这需要git来进行克隆，因此在git之外进行原始位复制将不起作用。

6 个答案:

答案 0 :(得分：28)

  

<强> PS 即可。公平警告：

     

git通常被认为是非常快。你应该尝试克隆来自darcs，bazaar，hg的完整回购（上帝保佑：TFS或颠覆......）。另外，如果你经常从头开始克隆完整的回购，你无论如何都会做错事。您始终只需git remote update即可获得增量更改。

     

有关保持完整 repos同步的各种其他方法，请参阅，例如

           

（包含其他相关SO帖子的链接）

愚蠢的副本

如前所述，您可以使用'dumb'文件传输复制存储库。

这肯定不会浪费时间压缩，重新包装，分层和/或过滤。

另外，你会得到

  • 钩
  • config（遥控器，推送分支，设置（空白，合并，别名，用户详细信息等）
  • stashes （另见Can I fetch a stash from a remote repo into a local branch?）
  • rerere cache
  • reflogs
  • 备份（来自filter-branch，例如）和其他各种事物（来自rebase，bisect等的中间状态）

这可能会或可能不成为您所需要的，但很高兴知道这一事实

捆绑

默认情况下，Git克隆会优化带宽。由于git clone默认情况下不会镜像所有分支（请参阅--mirror），因此只按原样转储包文件是没有意义的（因为这样可能会发送更多信息）超过要求）。

在分发给真正大的数量的客户时，考虑使用捆绑。

如果您想要一个没有服务器端成本的快速克隆， git方式是bundle create。您现在可以分发捆绑包，甚至不涉及服务器。如果您的意思是bundle... --all包含的内容不仅仅是git clone，请考虑以下事项： bundle ... master减少音量。

git bundle create snapshot.bundle --all # (or mention specific ref names instead of --all)

并分发快照包。这是两个世界中最好的，当然你不会从上面的项目符号列表中获得这些项目。在接收端，只是

git clone snapshot.bundle myclonedir/

压缩配置

您可以通过减少/删除压缩来降低服务器负载。 看看这些配置设置（我假设pack.compression可以帮助您降低服务器负载）

  

core.compression

     

整数-1..9，表示默认压缩级别。 -1是zlib的默认值。 0表示没有压缩，1..9是各种速度/大小权衡，9表示最慢。如果设置，则为其他压缩变量提供默认值，例如   core.loosecompression和pack.compression。

     

core.loosecompression

     

整数-1..9，表示不在包文件中的对象的压缩级别。 -1是zlib的默认值。 0表示没有压缩，1..9是各种速度/大小权衡，9表示最慢。如果未设置，则默认为   core.compression。如果未设置，则默认为1（最佳速度）。

     

pack.compression

     

整数-1..9，表示包文件中对象的压缩级别。 -1是zlib的默认值。 0表示没有压缩，1..9是各种速度/大小权衡，9表示最慢。如果未设置，则默认为core.compression。如果说   未设置，默认为-1，zlib默认值，这是“速度和压缩之间的默认折衷（当前等同于级别6）。”

     

请注意，更改压缩级别不会自动重新压缩所有现有对象。您可以通过将-F选项传递给git-repack（1）来强制重新压缩。

如果有足够的网络带宽，这个 实际上会导致更快的克隆。 当您决定对此进行基准测试时，不要忘记git-repack -F！

答案 1 :(得分：24)

使用深度创建浅层克隆。

git clone --depth 1 <repository>

答案 2 :(得分：4)

在意识到数据传输速度的上限之后，是在git“外部”建立的ssh连接我做了一些实验，发现使用pcsp（Putty scp）的上限是3,0正确选择了MB / s作为河豚加密方案。原始ftp的对照实验表明传输速度为3.1 MB / s，因此表明这是网络的上限。

这在vmware虚拟机管理程序中运行，并且当进行网络I / O的过程几乎100％使用cpu时，它表明瓶颈是Ubuntu网卡驱动程序。然后我发现即使安装了vmware工具，由于某种原因，内核仍然使用vlance驱动程序（模拟带有IRQ和所有的10 MBps网卡）而不是vmxnet驱动程序（直接与管理程序说话）。现在等待更改服务窗口。

换句话说，问题不是git而是底层的“硬件”。

答案 3 :(得分：1)

从日志中看，您似乎已经完成了克隆，如果您的问题是您需要在不同的计算机上多次执行此过程，则可以将存储库目录从一台计算机复制到另一台计算机。这种方式将保留每个副本与您克隆的存储库之间的关系（远程）。

答案 4 :(得分：1)

我正在标记git clone。

如果项目包含子模块，使用--jobs选项可以更快 例如：

    - name: SPRING_CLOUD_SCHEDULER_KUBERNETES_POD_ANNOTATIONS
      value:
    - name: SPRING_CLOUD_SCHEDULER_KUBERNETES_JOB_ANNOTATIONS
      value:

答案 5 :(得分：0)

git clone --depth=1 ... suggested in 2014在Git 2.22中将在2019年第二季度变得更快。
这是因为在最初的“ git clone --depth=...”部分克隆期间，它是 在大部分连接上花费时间是毫无意义的 检查枚举并跳过承诺对象（根据定义，这是从另一侧获取的所有对象）。
这已经优化了。

  

clone：对部分克隆进行更快的对象检查

     

对于部分克隆，进行完整的连接检查很浪费；我们跳过   承诺对象（对于部分克隆，是所有已知对象），以及   枚举它们以将它们从连接检查中排除   在大型存储库上花费大量时间。

     

至多，我们要确保获得由任何对象引用的对象   想要的裁判。
  对于部分克隆，只需检查这些对象是否已转移。

结果：

  Test                          dfa33a2^         dfa33a2
  -------------------------------------------------------------------------
  5600.2: clone without blobs   18.41(22.72+1.09)   6.83(11.65+0.50) -62.9%
  5600.3: checkout of result    1.82(3.24+0.26)     1.84(3.24+0.26) +1.1%

快62％！

相关问题
最新问题