我正在尝试克隆存储库。我第一次达到82％，然后它没有半小时的预算，所以我取消了克隆并重新开始。在那之后，每次我尝试克隆它，我得到6-10％之间，然后它失败并出现错误＆＃34;远程端意外挂断，早期EOF。＆＃34;我查找错误并尝试了我能找到的每个解决方案，最流行的解决方案是将postBuffer增加到最大尺寸。但是，它每次都会一直失败。
我不确定它是否有所作为，但我并没有尝试检查代码，这是大多数报告此问题的其他人似乎都在尝试做的事情。我试图克隆存储库。
答案 0 :(得分：2)
如果这是一个http事务，您需要联系BitBucket支持他们来诊断服务器端出了什么问题。
例如，＆＃34; howto/use-git-daemon＆＃34;：
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存储库上设置GIT_HTTP_MAX_REQUEST_BUFFER）
2015年5月20日commit 6bc0cb5旁边的Jeff King (peff)
（Junio C Hamano -- gitster --在commit 777e75b中合并，2015年6月1日）
测试改编自：Dennis Kaarsemaker (seveas)
新环境变量为GIT_HTTP_MAX_REQUEST_BUFFER：
GIT_HTTP_MAX_REQUEST_BUFFER环境变量（或http.maxRequestBuffer配置变量）可以设置为更改 git在获取期间将处理的最大ref协商请求;任何 需要更大缓冲区的提取将不会成功。通常不需要更改此值，但如果从具有极大数量的refs的存储库中提取，则可能会有所帮助。
可以使用单位指定值（例如，
100M表示100兆字节）。默认值为10兆字节。
解释非常有趣：
http-backend：假冒缓冲区协商请求缓冲区当
http-backend产生＆＃34;upload-pack＆＃34;要做参考 协商，它将http请求体流式传输到upload-pack，然后将http响应流回到 客户，因为它读 从理论上讲，git可以全双工;客户端在发送请求时可以使用我们的响应 然而，在实践中，HTTP是半双工协议 即使我们的客户端已准备好同时读写，我们也可能有其他HTTP基础设施，包括产生CGI的网络服务器或任何中间代理。In at least one documented case，这会导致死锁 在尝试通过http获取时 基本上会发生什么：
- Apache将请求代理到CGI，http-backend。
- http-backend gzip-inflates数据并将结果发送到upload-pack。
- upload-pack对数据进行操作，并通过管道将输出生成回Apache。 Apache没有阅读，因为它正在忙着写作（第1步）。
这大部分时间都可以正常工作，因为
upload-pack输出最终在系统管道缓冲区中，Apache读取 一旦完成写作。但如果两个请求 并且响应超过了系统管道缓冲区大小，那么我们 死锁（Apache阻止写入http-backend， http-backend阻止写入upload-pack和upload-pack 阻止写入Apache。）我们需要通过假设输入来打破僵局 或输出。在这种情况下，它是理想的假脱机输入， 因为Apache没有开始读取stdout 或 stderr直到我们消耗了所有输入。直到我们 这样做，我们甚至无法收到错误消息 客户端。
解决方案非常简单：我们阅读了请求 body进入http-backend的内存缓冲区，释放出来 Apache，然后将数据自己提供给
upload-pack。
答案 1 :(得分：0)
通过克隆单个分支或仅克隆一定数量的过去历史记录来减小存储库大小的一种选择。
git clone --depth=20 https://repo.git -b master
仅将master分支克隆到20次提交的深度。由于这是一个较小的实体，因此通常可以正常工作，然后可以获取其他分支。不知道是否可以在此之后恢复历史记录，但是对于很多无关紧要的案例来说，都是如此。