Git克隆：远程端意外挂断，尝试更改postBuffer但仍然失败

Posted 2023-02-22

【中文标题】Git克隆：远程端意外挂断，尝试更改postBuffer但仍然失败

【英文标题】：Git cloning: remote end hung up unexpectedly, tried changing postBuffer but still failing

【发布时间】：2015-04-18 16:47:51

【问题描述】：

我正在尝试克隆存储库。我第一次达到 82%，然后半小时没有让步，所以我取消了克隆并重新开始。之后，每次我尝试克隆它时，我都会得到 6-10%，然后它失败并出现错误“远程端意外挂断，早期 EOF”。我查找了错误并尝试了我能找到的所有解决方案，最流行的解决方案是将 postBuffer 增加到最大大小。但是，它仍然每次都失败。

我不确定这是否会有所不同，但我并没有尝试签入代码，而大多数其他报告此问题的人似乎都在尝试这样做。我正在尝试克隆存储库。

【问题讨论】：

您使用的是什么传输方式的克隆？

git bash，你是这个意思吗？

没有。我的意思是http/ssh/等？克隆 URI 是什么样的？ postBuffer 是一个 http 设置，与我相信的将数据发送到服务器有关。

http. URI 是 [e-mail]/emregan/wimco-dev.git

【参考方案1】：

通过克隆单个分支或仅克隆一定数量的过去历史记录来减少 repo 大小的一种选择。

git clone --depth=20 https://repo.git -b master

将仅将 master 分支克隆到 20 次提交的深度。由于这是一个小得多的实体，它通常可以工作，然后您可以在之后获取其他分支。不确定您是否可以恢复历史记录，但对于很多不重要的情况。

【讨论】：

如果以后您想扩展您的副本以包含完整的历史记录，您只需调用带有--unshallow 参数的fetch 命令：git fetch --unshallow

【参考方案2】：

如果这是一个 http 事务，您需要联系 BitBucket 支持，让他们诊断服务器端出了什么问题。 如“howto/use-git-daemon”中所述：

fatal: The remote end hung up unexpectedly

这只是表示某事出了问题。 要找出什么出了问题，您必须询问服务器。

请注意，当 BitBucket 将使用 Git 2.5+（2015 年第二季度）时，客户端可能会收到更明确的错误消息：

 request was larger than our maximum size xxx
 try setting GIT_HTTP_MAX_REQUEST_BUFFER"

（即在托管服务器的Git存储库上设置GIT_HTTP_MAX_REQUEST_BUFFER）

参见commit 6bc0cb5Jeff King (peff)，2015 年 5 月 20 日。^{（由 Junio C Hamano -- gitster -- 合并，commit 777e75b，2015 年 6 月 1 日）} 测试改编自：Dennis Kaarsemaker (seveas)

新的环境变量是GIT_HTTP_MAX_REQUEST_BUFFER:

GIT_HTTP_MAX_REQUEST_BUFFER 环境变量（或 http.maxRequestBuffer config 变量）可以设置为更改 git 在获取期间将处理的最大 ref 协商请求；任何 需要更大缓冲区的 fetch 不会成功。

此值通常不需要更改，但如果您从具有大量引用的存储库中获取，可能会有所帮助。

可以使用单位指定值（例如，100M 表示 100 兆字节）。默认值为 10 兆字节。

解释很有趣：

http-backend: spool ref 协商请求缓冲

当http-backend 产生“upload-pack”来做参考 协商，它将http请求正文流式传输到 upload-pack，然后将 http 响应流式传输回 客户端读取。 理论上，git可以走全双工；客户端可以在发送请求时使用我们的响应。 然而，在实践中，HTTP 是一种半双工协议。 即使我们的客户端准备好同时读取和写入，我们也可能有其他 HTTP 基础设施，包括生成 CGI 的网络服务器或任何中间代理。

In at least one documented case，这会导致死锁 尝试通过 http 获取时。 发生的事情基本上是：

Apache 将请求代理到 CGI，http-backend。 http-backend gzip-inflate 数据并将结果发送到upload-pack。 upload-pack 作用于数据并通过管道生成输出回 Apache。 Apache 没有读取，因为它正忙于写入（第 1 步）。

这在大多数情况下都可以正常工作，因为 upload-pack 输出最终在系统管道缓冲区中，Apache 读取 它一写完。但如果两者都要求 并且响应超过了系统管道缓冲区大小，那么我们 死锁（Apache 阻止写入 http 后端， http-backend 阻止写入上传包和上传包 阻止写入 Apache）。

我们需要通过假脱机输入来打破僵局 或输出。在这种情况下，最好对输入进行假脱机， 因为 Apache 不会开始读取标准输出 或 stderr 直到我们消耗完所有输入。所以直到我们 这样做，我们甚至无法将错误消息发送到 客户。

解决方案相当简单：我们阅读了请求 正文到 http 后端的内存缓冲区中，释放 Apache，然后自己将数据提供给upload-pack。

【讨论】：

如果通过 ssh 访问 git 时出现相同的错误“致命：远程端意外挂断错误：pack-objects dead of signal 13”怎么办？

@RobisonSantos 也许尝试检查您是否推送的对象太大而远程接收器无法处理：***.com/a/18560284/6309