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 年第 2 季度）时，客户端可能会收到更明确的错误消息：

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

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

请参阅Jeff King ( )于 2015 年 5 月 20 日提交的提交 6bc0cb5 。 ^{（由Junio C Hamano 合并 -- --于 2015 年 6 月 1 日提交 777e75b中）} 测试改编自：Dennis Kaarsemaker ( )peff
gitster
seveas

新的环境变量是GIT_HTTP_MAX_REQUEST_BUFFER：

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

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

该值可以用单位指定（例如，100M100 兆字节）。默认值为 10 兆字节。

解释很有趣：

http-backend：假脱机参考协商请求到缓冲区

当http-backend生成“ upload-pack”进行引用协商时，它将 http 请求正文流式传输到 upload-pack，然后 后者在读取时将 http 响应流式传输回客户端。
理论上，git 可以实现全双工；客户端可以在发送请求的同时使用我们的响应。
但实际上，HTTP 是半双工协议。
即使我们的客户端准备好同时读写，我们也可能有其他 HTTP 基础设施，包括生成 CGI 的 Web 服务器或任何中间代理。

至少在一个有记录的案例中，当尝试通过 http 获取数据时，这会导致死锁。
发生的情况基本上是：

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

这在大多数情况下都可以正常工作，因为upload-pack 输出最终会存储在系统管道缓冲区中，并且 Apache 在完成写入后会立即读取它。但是，如果请求和响应都超过系统管道缓冲区大小，则我们会死锁（Apache 阻止写入 http-backend，http-backend 阻止写入 upload-pack，upload-pack 阻止写入 Apache）。

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

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