我的git客户端在尝试克隆存储库一段时间后反复失败,出现以下错误。
这里的问题是什么?
注意:我已经向GIT托管提供商注册了我的SSH密钥
Receiving objects: 13% (1309/10065), 796.00 KiB | 6 KiB/s
fatal: The remote end hung up unexpectedly
我的git客户端在尝试克隆存储库一段时间后反复失败,出现以下错误。
这里的问题是什么?
注意:我已经向GIT托管提供商注册了我的SSH密钥
Receiving objects: 13% (1309/10065), 796.00 KiB | 6 KiB/s
fatal: The remote end hung up unexpectedly
当前回答
我有同样的错误,而使用BitBucket。我所做的是从我的回购的URL中删除https,并使用HTTP设置URL。
git remote set-url origin http://mj@bitbucket.org/mj/pt.git
其他回答
在/etc/resolv.conf中,将这一行添加到文件的末尾
options single-request
我也有同样的问题,正在网上搜索解决方案。我发现我们公司的IPv6路由没有维护。
我关闭了(在Windows 10的以太网端口上的IPv6选项),没有问题。
这是由于网络连接问题,我也遇到过同样的问题。 我做了一个浅层的代码副本使用
git clone --depth 1 //FORKLOCATION
稍后取消浅化克隆使用
git fetch --unshallow
快速的解决方案:
对于这种错误,我通常通过提高postBuffer大小开始:
git config --global http.postBuffer 524288000
(下面的一些评论报告称,该值必须翻倍):
git config --global http.postBuffer 1048576000
(对于npm发布,Martin Braun在评论中报告,将其设置为不超过5 000 000,而不是默认的1 000 000)
# # #更多信息:
从git配置手册页,http。postBuffer是关于:
智能HTTP传输在向远程系统发送数据时使用的缓冲区的最大字节大小。 对于大于这个缓冲区大小的请求,使用HTTP/1.1和Transfer-Encoding: chunked来避免在本地创建一个庞大的包文件。缺省值为1mib,满足大多数请求。
即使对于克隆来说,这也会产生影响,在这种情况下,OP Joe报告说:
[克隆]现在工作正常
注意:如果服务器端出现错误,并且服务器使用Git 2.5+ (Q2 2015),错误消息可能会更加明确。 参见“Git克隆:远程端意外挂起,尝试更改postBuffer但仍然失败”。
Kulai(在评论中)指出了这个Atlassian故障排除Git页面,它补充道:
错误代码56表示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“解决方案”。
参见brian m. carlson (bk2204)的commit 7a2dc95, commit 1b13e90(2020年1月22日)。 (由Junio C Hamano—gitster—在commit 53a8329,2020年1月30日合并) (Git邮件列表讨论)
文档:在增加http时提到。postBuffer很有价值 署名:布莱恩·m·卡尔森
Users in a wide variety of situations find themselves with HTTP push problems. Oftentimes these issues are due to antivirus software, filtering proxies, or other man-in-the-middle situations; other times, they are due to simple unreliability of the network. However, a common solution to HTTP push problems found online is to increase http.postBuffer. This works for none of the aforementioned situations and is only useful in a small, highly restricted number of cases: essentially, when the connection does not properly support HTTP/1.1. Document when raising this value is appropriate and what it actually does, and discourage people from using it as a general solution for push problems, since it is not effective there.
git配置http的文档。postBuffer现在包括:
http.postBuffer
Maximum size in bytes of the buffer used by smart HTTP transports when POSTing data to the remote system. For requests larger than this buffer size, HTTP/1.1 and Transfer-Encoding: chunked is used to avoid creating a massive pack file locally. Default is 1 MiB, which issufficient for most requests. Note that raising this limit is only effective for disabling chunked transfer encoding and therefore should be used only where the remote server or a proxy only supports HTTP/1.0 or is noncompliant with the HTTP standard. Raising this is not, in general, an effective solution for most push problems, but can increase memory consumption significantly since the entire buffer is allocated even for small pushes.
对于共享带宽,尝试在负载较小时进行克隆。否则,请尝试高速连接。如果仍然不工作,请使用以下命令,
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
再试着克隆一次。您可能需要根据可用内存大小更改这些设置。