git克隆的时候，远端意外挂了
尝试复制存储库一段时间后，我的git客户端反复失败，出现以下错误。
这里可能是什么问题？
注意：我已经通过GIT托pipe服务提供商注册了我的SSH密钥
Receiving objects: 13% (1309/10065), 796.00 KiB | 6 KiB/s fatal: The remote end hung up unexpectedly
快速解决：
有了这种错误，我通常通过以下方式来提高postBuffer大小：
git config --global http.postBuffer 524288000
（下面的一些评论报告必须加倍价值）：
git config --global http.postBuffer 1048576000
更多信息：
从git config手册页 ， http.postBuffer是关于：
将数据发布到远程系统时，智能HTTP传输所使用的缓冲区的最大大小（以字节为单位）。
对于大于此缓冲区大小的请求，将使用HTTP / 1.1和Transfer-Encoding: chunked来避免在本地创build大量的包文件。 默认值是1 MiB，这对于大多数请求来说已经足够了。
即使是克隆，也可以产生效果，在这种情况下， OP Joe报告：
[克隆]现在工作正常
注意：如果服务器端出现问题，并且服务器使用Git 2.5+（Q2 2015），则错误消息可能更加明确。
看到“ Git克隆：远程挂起意外，试图改变postBuffer但仍然失败 ”。
古来 （ 在评论中 ）指出了这个Atlassian疑难解答Git页面 ，它增加了：
Error code 56表示curl接收错误CURLE_RECV_ERROR，这意味着有一些问题阻止了在克隆过程中接收数据。
通常，这是由于networking设置，防火墙，VPN客户端或反病毒软件在所有数据传输完毕之前都会终止连接。
它还提到了以下环境variables，以帮助debugging过程。
# Linux export GIT_TRACE_PACKET=1 export GIT_TRACE=1 export GIT_CURL_VERBOSE=1 #Windows set GIT_TRACE_PACKET=1 set GIT_TRACE=1 set GIT_CURL_VERBOSE=1
http.postBuffer技巧不适合我。 然而：
对于遇到此问题的其他人，这可能是GnuTLS的问题。 如果您设置了详细模式，您可能会看到下面的代码行中的底层错误。
不幸的是，到目前为止，我唯一的解决scheme是使用SSH。
我看过其他地方发布的解决scheme，用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
以上都没有为我工作，但这是什么： https : //stackoverflow.com/a/22317479
我收到的完整的错误信息是：
fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed
Obs .:更改http.postBuffer可能还需要通过调整client_max_body_size的值来设置http.postBuffer的Nginxconfiguration文件来接受客户端的较大主体大小。
但是，如果您有权访问Gitlab机器或其networking中的计算机，并且使用git bundle ，则有一种解决方法 。
- 去源机器上你的git仓库
- 运行
git bundle create my-repo.bundle --all - 将（例如，使用rsync）my-repo.bundle文件传输到目标机器
- 在目标机器上运行
git clone my-repo.bundle -
git remote set-url origin "path/to/your/repo.git" -
git push
祝一切顺利！
在/etc/resolv.conf添加行到文件末尾
options single-request
使用以下命令后我得到了解决scheme：
git repack -a -f -d --window=250 --depth=250
如果您使用的是https，并且出现错误。
我使用https而不是http，它解决了我的问题
git config --global https.postBuffer 524288000
我有一个类似的问题，但有一个竹工作。 Bamboo在做一个caching仓库的本地克隆（在本地但通过一个SSH代理）失败，我删除了caching，之后它工作，但是任何时候它试图从本地caching中克隆都是失败的。 看起来像竹代码版本的SSH代理不是git本身的问题。
当从弹性beanstalkpipe理的AWS EC2实例上托pipe的远程git仓库克隆数据（通过HTTP）时，我正面临着这个问题。 克隆本身也是在AWS EC2实例上完成的。
我尝试了所有上述解决scheme及其组合：
- 设置git的
http.postBuffer - 设置
http.maxrequestbuffer - closuresgit压缩并尝试“浅”
git clone，然后git fetch --unshallow– 看到致命的：早期EOF致命的：索引包失败 -
packedGitLimitGIT内存设置 –packedGitLimit等，看到这里： 致命的：早期的EOF致命的：索引包失败 - 调整nginxconfiguration – 设置
client_max_body_size为大值和0（无限）; 设置proxy_request_buffering off; - 在/etc/resolv.conf中设置
options single-request - 用涓stream调节git客户端吞吐量
- 使用strace来追踪
git clone - 考虑更新git客户端
毕竟，我仍然一次又一次地面对同样的问题，直到我发现问题是在弹性负载平衡器（ELB）切割连接 。 直接访问EC2实例（一个托pipegit仓库），而不是通过ELB，我终于设法克隆git仓库！ 我仍然不确定ELB（超时）参数中的哪一个对此负责，所以我仍然需要做一些研究。
UPDATE
看起来，通过将超时时间从20秒提高到300秒，更改了AWS Elastic Load Balancer的“连接耗尽”策略，为我们解决了这个问题。
git clone错误与“连接耗尽”之间的关系是奇怪的，对我们来说并不明显。 可能是连接耗尽超时更改导致了ELBconfiguration中的一些内部更改，从而解决了过早closures连接的问题。
这是AWS论坛上的相关问题（没有答案）： https : //forums.aws.amazon.com/thread.jspa?threadID=258572
与Bitbucket相同的错误。 由…修复
git config --global http.postBuffer 524288000 git config --global http.maxRequestBuffer 100M git config --global core.compression 0
我也有同样的问题。这个问题的原因是作为柯蒂斯关于GNUTLS的描述。
如果你有相同的原因，你的系统是Ubuntu，你可以通过从ppa:git-core/ppa安装最新版本的git来解决这个问题。命令如下。
sudo add-apt-repository ppa:git-core/ppa sudo apt-get update sudo apt-get git
这可能与服务器问题一样简单。 如果使用GitHub，请检查https://twitter.com/githubstatus 。 我刚才第一次看到这个，发现GitHub有摇摆 。 几分钟后，它再次罚款。
这为我工作，设置谷歌名称服务器，因为没有指定标准名称服务器，然后重新启动networking：
sudo echo "dns-nameservers 8.8.8.8" >> /etc/network/interfaces && sudo ifdown venet0:0 && sudo ifup venet0:0
我在Kubuntu使用git面临这个问题。 我也注意到networking的整体不稳定性，并find了一个解决scheme 。
在/etc/resolv.conf中添加行到文件末尾
选项单一请求
这个固定的延迟在每个域名parsing和git之后开始像一个魅力工作。
那么，我想推一个219 MB的解决scheme，但我没有运气
git config --global http.postBuffer 524288000
无论如何有一个525 MB的后缓冲区有什么意义？ 这很愚蠢。 所以我看了下面的git错误：
Total 993 (delta 230), reused 0 (delta 0) POST git-receive-pack (5173245 bytes) error: fatal: RPC failed; curl 56 SSL read: error:00000000:lib(0):func(0):reason(0), errno 10054
所以git想要发布5 MB，然后我做了后缓冲区6 MB，它的工作原理
git config --global http.postBuffer 6291456
我是从我的OS X EI Capitan Mac做git推。 我得到相同的错误，我试图一切修复，我发现在谷歌/ stackoverflow。 至于版本而言，我使用的是2.7.4的相当最新版本的github。 我在本地系统中创build了一个项目，我希望这个项目在我的github帐户中公开。 项目大小不在8MB左右。 我注意到，当我推送一些大小约1.5MB的文件时，它正在推送正确，但是对于我来说大尺寸失败，同样的错误，
我唯一的select是推动大块MB的变化。 现在我推动了所有的变化。 这是我的解决方法，直到我得到解决这个解决scheme。
所以你也可以尝试在多次提交中推送更改。 或者，如果您有多个文件夹，则可以按每个文件夹推送更改（如果文件夹大小不大）。
希望这能帮助你继续工作。
唯一对我有用的是使用HTTPS链接克隆回购，而不是SSH链接。
我发现我的问题是与.netrc文件，如果是的话，那么你可以做到以下几点：
打开.netrc文件并编辑它以包含github凭据。 inputnano ~/netrc或gedit ~/netrc
然后包括以下内容：* machine github.com
login用户名
密码SECRET
机器api.github.com
login用户名
密码SECRET *
你可以在那里包括你的原始密码，但出于安全的目的，在这里生成一个身份validation令牌github令牌，并粘贴它的地方的密码。
希望这有助于某人
使用BitBucket时，我有同样的错误。 我所做的是从我的回购url中删除https，并使用HTTP设置url。
git remote set-url origin http://mj@bitbucket.org/mj/pt.git
我有同样的问题，它与一个糟糕的互联网连接有关，所以尝试了一些gitconfiguration后，我刚刚断开连接，并再次连接，它的工作！
似乎连接失败（或引发这种情况的行为），git卡住了。
我希望这可以帮助更多的人在这里。
最好，
检查您的互联网速度。 同时检查以下命令：
$ git config --global http.postBuffer 2M $ git pull origin master
