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

Question

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

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

Answer 1

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

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

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

Answer 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 获取时。
发生的事情基本上是：

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

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

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

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