我正在尝试将代码第一次推送到我的git存储库但是我收到以下错误:
Counting objects: 222026, done. Compressing objects: 100% (208850/208850), done. Write failed: Broken pipe222026) error: pack-objects died of signal 13 fatal: The remote end hung up unexpectedly error: failed to push some refs to 'ssh://git@bitbucket.org/<...>'
我尝试增加http缓冲区大小(git config http.postBuffer 524288000
),我尝试git repack
,但它没有用。
我能够将一个非常相似的大小代码推送到另一个存储库(它不像这个那样工作,但在git repack
确实有效之后)。我正试着把它推到bitbucket。
有什么想法吗?
答案 0 :(得分:29)
简单的解决方案是增加HTTP post缓冲区大小,以允许更大的块被推送到远程仓库。为此,只需输入:
git config http.postBuffer 52428800
该数字以字节为单位,因此在这种情况下我将其设置为50MB。默认值为1MB。
答案 1 :(得分:6)
因为我没有看到这个答案:更改您的Wifi网络。我在阻止我,并给了我broken pipe
错误。将我的iPhone用作热点后,它可以完美运行!
答案 2 :(得分:3)
在VMWare上使用Arch发行版时遇到了这个问题。
添加
IPQoS=throughput
对我的ssh config(〜/ .ssh / config)来说,这很有帮助。
答案 3 :(得分:1)
我遇到了同样的问题,这对我有用:
git gc --aggressive --prune
花费了一段时间,但完成后,所有git操作开始更快地运行。
先前失败的推送操作随后成功了,可能是因为它足够快,可以避免某些超时相关的问题。
答案 4 :(得分:0)
请注意,当包文件损坏时(即包对象失败),推送仍然可以冻结(即使postBuffer增加)
这将在git 2。9(2016年6月)修复
commit c4b2751见commit df85757,commit 3e8b06d,commit c792d7b,commit 739cf49,Jeff King (peff
)(2016年4月19日){。}}。
(由Junio C Hamano -- gitster
--合并于commit d689301,2016年4月29日)
&#34;
git push
&#34;来自腐败的存储库,试图推动大量的refs死锁;在接收端的主线程注意到推送失败并决定不读取这些通知并返回失败后,将这些ref更新中止的拒绝通知的线程阻止写入主线程。
Commit 739cf49包含所有细节。
send-pack
:在完成异步过程之前关闭demux管道这可以修复从损坏的repo中推送大量refs时客户端的死锁。
答案 5 :(得分:0)
在将我的千兆字节数据上传到github存储库时遇到了同样的问题。增加HTTP缓冲区大小不适用于此大小的数据。我不确定它是git本身还是github服务器的问题。无论如何,我做了一个shell脚本来处理这个问题,它逐步上传当前目录中的文件,每步少于100 MB的数据。它对我来说很好。这需要时间,但我可以分离屏幕并等待一夜。
这是shell脚本: https://gist.github.com/sekika/570495bd0627acff6c836de18e78f6fd
答案 6 :(得分:0)
我不确定为什么,但是我遇到了这个问题,当我从无线网络的“ 5G”版本切换到另一个时,问题就消失了