http。postBuffer的把戏对我没用。然而:

对于遇到此问题的其他人，这可能是GnuTLS的问题。如果您设置了Verbose模式，您可能会看到下面代码行所示的基本错误。

不幸的是，到目前为止我唯一的解决方案是使用SSH。

我在其他地方看到过用OpenSSL而不是GnuTLS编译Git的解决方案。这里有一个针对该问题的活动错误报告。

GIT_CURL_VERBOSE=1 git clone https://github.com/django/django.git

Cloning into 'django'...
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.131... * Connected to github.com (192.30.252.131) port 443 (#0)
* found 153 certificates in /etc/ssl/certs/ca-certificates.crt
*    server certificate verification OK
*    common name: github.com (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: 
*    start date: Mon, 10 Jun 2013 00:00:00 GMT
*    expire date: Wed, 02 Sep 2015 12:00:00 GMT
*    issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV CA-1
*    compression: NULL
*    cipher: ARCFOUR-128
*    MAC: SHA1
> GET /django/django.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.8.4
Host: github.com
Accept: */*
Accept-Encoding: gzip

Pragma: no-cache
< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Thu, 10 Oct 2013 03:28:14 GMT

< Content-Type: application/x-git-upload-pack-advertisement
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
< 
* Connection #0 to host github.com left intact
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.131... * connected
* found 153 certificates in /etc/ssl/certs/ca-certificates.crt
* SSL re-using session ID
*    server certificate verification OK
*    common name: github.com (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: 
*    start date: Mon, 10 Jun 2013 00:00:00 GMT
*    expire date: Wed, 02 Sep 2015 12:00:00 GMT
*    issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV CA-1
*    compression: NULL
*    cipher: ARCFOUR-128
*    MAC: SHA1
> POST /django/django.git/git-upload-pack HTTP/1.1
User-Agent: git/1.8.4
Host: github.com
Accept-Encoding: gzip

Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result
Content-Encoding: gzip
Content-Length: 2299
* upload completely sent off: 2299out of 2299 bytes

< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Thu, 10 Oct 2013 03:28:15 GMT

< Content-Type: application/x-git-upload-pack-result
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
< 
remote: Counting objects: 232015, done.
remote: Compressing objects: 100% (65437/65437), done.
* GnuTLS recv error (-9): A TLS packet with unexpected length was received.
* Closing connection #0
error: RPC failed; result=56, HTTP code = 200
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

当我从由elastic beanstalk管理的AWS EC2实例上托管的远程git repo克隆数据(通过HTTP)时，我就遇到了这个问题。 克隆本身也是在AWS EC2实例上完成的。

我尝试了上述所有的解决方案以及它们的组合:

setting git's http.postBuffer settinghttp.maxrequestbuffer turning off git compression and trying "shallow" git clone and then git fetch --unshallow - see fatal: early EOF fatal: index-pack failed tunning GIT memory settings - packedGitLimit et al, see here: fatal: early EOF fatal: index-pack failed tunning nginx configuration - setting client_max_body_size to both big value and 0 (unlimited); setting proxy_request_buffering off; setting options single-request in /etc/resolv.conf throttling git client throughput with trickle using strace for tracing git clone considering update of git client

在所有这些之后，我仍然一次又一次地面临同样的问题，直到我发现这个问题是在弹性负载均衡器(ELB)切断连接。 在直接访问EC2实例(一个托管git repo)而不是通过ELB之后，我终于成功克隆了git repo! 我仍然不确定是哪个ELB(超时)参数导致了这一点，所以我仍然需要做一些研究。

更新

改变AWS弹性负载均衡器的连接耗尽策略，将超时时间从20秒提高到300秒，似乎为我们解决了这个问题。

git克隆错误和“连接耗尽”之间的关系很奇怪，对我们来说并不明显。可能是连接耗尽超时更改导致ELB配置中的一些内部更改，从而修复了过早关闭连接的问题。

这是AWS论坛上的相关问题(还没有答案):https://forums.aws.amazon.com/thread.jspa?threadID=258572

对于共享带宽，尝试在负载较小时进行克隆。否则，请尝试高速连接。如果仍然不工作，请使用以下命令，

git config --global http.postBuffer 2048M
git config --global http.maxRequestBuffer 1024M
git config --global core.compression 9

git config --global ssh.postBuffer 2048M
git config --global ssh.maxRequestBuffer 1024M

git config --global pack.windowMemory 256m 
git config --global pack.packSizeLimit 256m

再试着克隆一次。您可能需要根据可用内存大小更改这些设置。

我也遇到过类似的问题，不过是竹子做的活。竹是失败的做本地克隆(本地但通过SSH代理)缓存的存储库，我删除了缓存，之后它工作了，但任何时候它试图从本地缓存克隆有一个失败。似乎是bamboo的SSH代理版本的问题，而不是git本身。

我发现我的问题是与.netrc文件，如果是这样，那么你也可以做以下:

打开你的.netrc文件并编辑它以包含github凭证。 输入nano ~/netrc或gedit ~/netrc

然后包括以下内容: *机器github.com

登录用户名

密码的秘密

机器api.github.com

登录用户名

密码的秘密*

你可以在那里包括你的原始密码，但出于安全考虑，在这里生成一个认证令牌github令牌，并粘贴它在你的密码的地方。

希望这对大家有所帮助

上面的技巧对我没有帮助，因为repo比github允许的最大推送大小还要大。有效的方法是来自https://github.com/git-lfs/git-lfs/issues/3758的建议，建议每次推一点:

If your branch has a long history, you can try pushing a smaller number of commits at a time (say, 2000) with something like this: git rev-list --reverse master | ruby -ne 'i ||= 0; i += 1; puts $_ if i % 2000 == 0' | xargs -I{} git push origin +{}:refs/heads/master That will walk through the history of master, pushing objects 2000 at a time. (You can, of course, substitute a different branch in both places if you like.) When that's done, you should be able to push master one final time, and things should be up to date. If 2000 is too many and you hit the problem again, you can adjust the number so it's smaller.