Question 1

Quick solution:

对于这种错误，我通常先将postBuffer的大小提高。

git config --global http.postBuffer 524288000
(下面的一些评论报告说不得不把数值翻倍)。
git config --global http.postBuffer 1048576000
(For npm publish, 马丁-布劳恩 reports in the comments将其设置为不超过50 000 000，而不是默认的1 000 000)
###更多信息。
From the git config man page, http.postBuffer is about:
智能HTTP传输系统在向远程系统发送数据时使用的缓冲区的最大尺寸（字节）。

对于大于这个缓冲区大小的请求，使用HTTP/1.1和Transfer-Encoding: chunked来避免在本地创建一个巨大的包文件。默认值为1 MiB，这对大多数请求来说是足够的。
即使对克隆人来说，这也会产生影响，在这个例子中，也是如此。OP Joe reports:
[clone] works fine now
注意：如果服务器端出了问题，而且服务器使用的是Git 2.5+（2015年第二季度），错误信息可能会更明确。

See "Git克隆：远程端意外挂起，尝试改变postBuffer但仍然失败".
Kulai (in the comments) points out to 这个Atlassian Troubleshooting Git页面，其中补充道。
替换代码8】表示Curl接收到CURLE_RECV_ERROR的错误，这意味着在克隆过程中存在一些问题，导致数据无法被接收。

通常，这是由网络设置、防火墙、VPN客户端或反病毒造成的，它们在所有数据传输之前就终止了连接。
它还提到了以下环境变量，以帮助调试过程。
# 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
有了Git 2.25.1（2020年2月），你就会对这个http.postBuffer有更多了解。"解决方案"。
See 提交7a2dc95, commit 1b13e90(2020年1月22日)由brian m. carlson (bk2204).

^{(Merged by Junio C Hamano -- gitster -- in 提交53a8329, 2020年1月30日)}

(Git邮件列表讨论)
docs: mention when increasing http.postBuffer is valuable
^{签名：Brian M. Carlson}
在各种各样的情况下，用户都会发现自己有HTTP推送问题。
很多时候，这些问题是由于防病毒软件、过滤代理或其他中间人的情况造成的；其他时候，它们是由于网络的简单不可靠。
然而，网上发现的一个解决HTTP推送问题的常见方法是增加http.postBuffer。
这对上述情况都不起作用，只在少数高度限制的情况下有用：基本上，当连接不能正确支持HTTP/1.1时。
记录什么时候提高这个值是合适的，以及它的实际作用，并劝阻人们不要把它作为推送问题的一般解决方案，因为它在那里是无效的。
因此，在文件中对git config http.postBuffer now includes:
http.postBuffer
智能HTTP传输系统在向远程系统发送数据时使用的缓冲区的最大尺寸（字节）。

对于大于这个缓冲区大小的请求，HTTP/1.1和Transfer-Encoding: chunked被使用，以避免在本地创建一个巨大的包文件。

默认为1 MiB，对大多数请求来说已经足够。
请注意，提高这个限制只对禁用分块传输编码有效，因此只应在远程服务器或代理只支持HTTP/1.0或不符合HTTP标准时使用。

一般来说，提高这一点对大多数推送问题来说不是一个有效的解决方案，但会大大增加内存消耗，因为即使是小的推送也要分配整个缓冲区。.

Question 2

Bitbucket也有同样的错误。修正者 git config --global http.postBuffer 500M git config --global http.maxRequestBuffer 100M git config --global core.compression 0

Question 3

The http.postBuffer trick did not work for me. However: 对于其他遇到这个问题的人来说，这可能是GnuTLS的一个问题。如果你设置了Verbose模式，你可能会看到潜在的错误看起来与下面的代码类似。不幸的是，到目前为止，我唯一的解决办法是使用SSH。我见过一个解决方案的帖子elsewhere用OpenSSL而不是GnuTLS来编译Git。这个问题有一个活跃的错误报告here. 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

Question 4

基于这个答案, I tried following (with https url): initial cloning of repo: git clone --depth 25 url-here fetch commits with increasing twice per try depth: git fetch --depth 50 git fetch --depth 100 git fetch --depth 200 ...等等。 eventually (when I think enough is fetched) I run git fetch --unshallow - and it's done. 这个过程显然需要更多的时间，但在我的案例中，设置http.postBuffer和core.compression并没有帮助。 UPD:我发现，通过ssh对任何 repo 大小都有效（意外发现），用git clone <ssh url>完成，因为你已经创建了 ssh 密钥。一旦获取了 repo，我就用git remote set-url <https url to repo>改变远程地址。

Question 5

对我来说，唯一有效的方法是使用以下方法克隆 repo。HTTPS的链接，而不是SSH link.

Question 6

这是由于网络连接问题，我也面临同样的问题。我做了一个浅显的代码拷贝，使用 git clone --depth 1 //FORKLOCATION 后来又用以下方法取消了克隆的许可 git fetch --unshallow

Question 7

对于共享带宽，尝试在负载较少时克隆。否则，请尝试使用高速连接。如果仍然不成功，请使用下面的命令。 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 并尝试再次克隆。你可能需要根据你的可用内存大小来改变这些设置。

Question 8

观察..:改变http.postBuffer可能还需要为gitlab设置Nginx配置文件，通过调整client_max_body_size的值来接受更大的客户端尺寸。不过，如果你能访问Gitlab的机器，也有一个解决方法或到其网络中的一台机器，那是通过利用git bundle。 go to your git repository on the source machine run git bundle create my-repo.bundle --all transfer (eg., with rsync) the my-repo.bundle file to the destination machine on the destination machine, run git clone my-repo.bundle git remote set-url origin "path/to/your/repo.git" git push 万事如意!

Question 9

如果你使用的是https，而你得到的是错误。我用https代替了http，它解决了我的问题。 git config --global https.postBuffer 524288000

Question 10

我在使用以下命令后得到了解决。 git repack -a -f -d --window=250 --depth=250

Question 11

我也遇到了同样的问题。我用试验和错误的方法解决了这个问题。我改变了core.compression的值，直到它发挥作用。我从 "git config --global core.compression 1 "开始，尝试了3次之后 "git config --global core.compression 4 "对我有用。

Question 12

好吧，我想推一个219MB的解决方案，但我没有运气与 git config --global http.postBuffer 524288000 而且，有一个525MB的帖子缓冲区有什么意义呢？这很傻。所以我看了看下面的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想发5MB的帖子，然后我把帖子的缓冲区设为6MB，结果成功了 git config --global http.postBuffer 6291456

Question 13

当我从由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秒，为我们解决了这个问题。替换代码2】错误和 "连接耗尽 "之间的关系很奇怪，对我们来说并不明显。可能是连接耗尽的超时变化导致ELB配置的一些内部变化，修复了过早关闭连接的问题。这是AWS论坛上的相关问题（还没有答案）。https://forums.aws.amazon.com/thread.jspa?threadID=258572

Question 14

在/etc/resolv.conf中，将该行添加到文件的末尾。 options single-request

Question 15

我也有同样的问题，与网络连接不良有关，所以在尝试了一些git配置后，我刚刚断开了网络连接，又重新连接，就成功了! 似乎在连接丢失后（或引发这种情况的动作），git就被卡住了。我希望它能对这里的更多人有所帮助。 Best,

Question 16

我也有同样的问题。这个问题的原因正如Kurtis对GNUTLS的描述。如果你有同样的原因，并且你的系统是Ubuntu，你可以通过从ppa:git-core/ppa安装最新版本的git来解决这个问题，命令如下。 sudo add-apt-repository ppa:git-core/ppa sudo apt-get update sudo apt-get git

Question 17

浪费了几个小时来尝试这些解决方案，但最终追踪到这是企业的IPS（入侵保护系统）在传输一定数量的数据后放弃了连接。

Question 18

增加postBuffer大小和maxRequestBuffer将帮助你解决这个问题。请按照以下步骤操作。 steps: 1 .打开终端或Git Bash，用 "cd "转到你想克隆 repo 的位置。 2.Set compression to 0 git config --global core.compression 0 3.设置postBuffer大小 git config --global http.postBuffer 1048576000 4.设置maxRequestBuffer大小 git config --global http.maxRequestBuffer 100M 5.现在开始克隆 git clone <repo url> 6.等待，直到克隆完成。谢谢你。编码快乐！！！。

Question 19

我有一个类似的问题，但是是在竹子的工作中。 Bamboo在本地克隆（本地但通过SSH代理）一个缓存的版本库时失败了，我删除了缓存，之后就成功了，但任何时候它试图从本地缓存克隆都会失败。看起来是竹子的SSH代理版本的问题，而不是git本身的问题。

Question 20

我在Kubuntu中使用git时遇到了这个问题。我还注意到网络的整体不稳定，并发现了一个solution. 在/etc/resolv.conf中将这一行添加到文件的末尾 options single-request 这就解决了每次域名解析前的延迟问题，之后git就开始工作得很好。

Question 21

SOLVED WITH WIFI Router Setting : 当我在WIFI上使用PPPoE设置（由WIFI路由器自动登录）时，我也遇到了同样的问题。 Git的下载速度非常慢，只有15kb。 packet_write_wait:连接到17.121.133.16端口22：管道断裂致命：远程端意外挂断了致命：早期EOF 致命：索引打包失败解决方案: 1.将设置改为动态IP，重新启动wifi路由器。 2.2.从网络浏览器登录到互联网服务提供商的门户网站（不要配置PPPoE，从wifi路由器自动登录）。更改Git后，下载速度为1.7MB。

Question 22

用ssh代替http，这不是一个好的答案，但至少对我来说是有效的。

Question 23

This solved my problem: git clone --depth=20 https://repo.git -b master

Question 24

上面的技巧并没有帮助我，因为该 repo 大于 github 允许的最大推送尺寸。有用的是一个建议，来自https://github.com/git-lfs/git-lfs/issues/3758其中建议一次推一点。如果你的分支有很长的历史，你可以试着每次推送一个较少的一次推送较少的提交量（比如2000个），具体方法如下。 git rev-list --reverse master | ruby -ne 'i ||= 0; i += 1; puts $_ if i % 2000 == 0' | xargs -I{} git push origin +{}:refs/heads/master 这将浏览master的历史，每次推送2000个对象。(当然，你也可以在这两个地方用不同的分支代替替换不同的分支，如果你愿意的话）。完成后，你应该可以推送 master，一切就都是最新的了。如果2000个太如果2000个太多，而且你又遇到了问题，你可以调整这个数字，使之更

Question 25

我不得不删除git clone命令的分支标志。

Question 26

在MacOSX High Sierra上，我的解决方案是。 brew install git-lfs 而我的版本库被克隆了，没有任何错误。

Question 27

这可能是一个简单的服务器问题。如果使用GitHub，请检查https://twitter.com/githubstatus.我刚才第一次看到这个，发现GitHub发生了动荡.几分钟后，它又能正常工作了。

Question 28

这对我来说很有效，因为没有指定标准的名字服务器，所以设置了Googles的名字服务器，随后重新启动网络。 sudo echo "dns-nameservers 8.8.8.8" >> /etc/network/interfaces && sudo ifdown venet0:0 && sudo ifup venet0:0

Question 29

我发现我的问题出在.netrc文件上，如果你也是这样，那么你可以做以下工作。打开你的.netrc文件，并编辑它以包括github凭证。输入nano ~/netrc或gedit ~/netrc。然后包括以下内容。 *machine github.com 登录用户名密码SECRET 机器api.github.com 登录用户名密码SECRET* 你可以在这里包括你的原始密码，但为了安全起见，在这里生成一个授权令牌github token并将其粘贴在密码的位置上。 Hope this helps someone

Quick solution:

`docs`: mention when increasing http.postBuffer is valuable

`http.postBuffer`