Git 使用_git buffersize

Git 技巧

子模块下载失败

例如 git clone --recursive https://github.com/caffe2/caffe2
网络不好或者其他原因导致子模块没有下载完全，这时用git pull是无法下载完全的。

如果你确定主模块已完成下载，而不确定子模块是否都已经下载完全了，可以以下命令进行确认
git submodule update --init --recursive

git clone 失败

近来在新电脑上出现 git clone 失败的情况
git clone --recursive https://github.com/caffe2/caffe2
提示如下（类似）

error: RPC failed; curl 56 GnuTLS recv error (-9): A TLS packet with unexpected length was received.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
1
2
3
4

该现象每次必现，奇怪的是，在其他机器上却并未出现，应该排除网络原因。尝试使用git clone --depth=1 ...结果成功，难道是与repo过大有关系？
各种搜索后，目前有以下解决方案

• 方法1，Rebuilding git with opensslinstead of gnutls，有分析称这并未Git的bug，而是gnutls的，但这个办法过于麻烦，不打算尝试了，参考链接
• 方法2，git config --global http.postBuffer 524288000，增加缓存大小，如果还是不行，就再加大。原理大概是smart HTTP传输和buffer size的关系，不明白，搜索到不少内容说增加buffer能够work，但是也有说不work的，我表示怀疑，原因是在一台git没有问题，无需代理的机器上，我将buffer设置为仅有5M，依然能够git clone成功，不管怎么样，明天尝试一下，此方法最简单，参考链接
• 方法3，先通过git clone --depth=1 ...，再git clone --unshallow，此法很多人点赞，不过回答时间较早。具体方法
  git config --global core.compression 0
git clone --depth 1 <repo_URI>
git fetch --unshallow or git fetch --depth=2147483647
git pull --all
  如果此法奏效，倒是提供了一个快速 git clone 的方法，配合之前提到的git submodule update --init --recursive可以避免网路不畅导致的各种问题，此法值得尝试，参考链接
• 方法4，使用ssh，不使用https，由于工作机需要代理访问网络，使用ssh搞不定代理，此法不作考虑
• 方法5，还有说换个路径重新clone成功的，参考链接，#14楼

今天尝试换路径+调大buffer仍然不work，再次设置git config --global http.sslVerify false并clone，成功！

结论

• 还是网速不给力，导致下载内容不完整，找网速好的时候多试几次，无他
• git clone --recursive https://... = git clone https://... + git submodule update --init --recursive 这招很好用
• git clone --depth 1 是个办法，后续的 git fetch --unshallow 还未尝试