blocks|key|172660|text|简单的解决方案是增加HTTP+post缓冲区大小，以允许将更大的块推送到远程存储库。为此，只需键入：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|172661|git+config+http.postBuffer+52428800|code-block|syntax|javascript|172662|这个数字是以字节为单位的，所以在本例中我将其设置为50MB。默认值为1MB。|172663|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Simple solution is to increase the HTTP post buffer size to allow for larger chunks to be pushed up to the remote repo. To do that, simply type:

<pre><code>git config http.postBuffer 52428800
</code></pre>

The number is in bytes, so in this case I have set it to 50MB. The default is 1MB.

blocks|key|176331|text|我在将我的to数据上传到github存储库时遇到了同样的问题。增加HTTP缓冲区大小对此大小的数据无效。我不确定这是git本身的问题还是github服务器的问题。无论如何，我做了一个shell脚本来处理这个问题，它一步一步地上传当前目录中的文件，每一步都少于100MB的数据。它对我来说运行得很好。这需要时间，但我可以分离屏幕，并等待一夜。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|176332|下面是shell脚本：https://gist.github.com/sekika/570495bd0627acff6c836de18e78f6fd|offset|length|176333|entityMap|0|LINK|mutability|MUTABLE|url|https://gist.github.com/sekika/570495bd0627acff6c836de18e78f6fd^0|0|B|1R|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

I met the same problem when uploading my gigabytes of data to github repository. Increasing the HTTP buffer size did not work for this size of data. I am not sure if it is a problem of git itself or github server. Anyway I made a shell script to handle this problem, which uploades files in the current directory step by step, in each step less than 100 MB of data. It is working fine for me. It takes time but I can just detach screen and wait overnight.

Here is the shell script:
<a href="https://gist.github.com/sekika/570495bd0627acff6c836de18e78f6fd" rel="nofollow">https://gist.github.com/sekika/570495bd0627acff6c836de18e78f6fd</a>

blocks|key|173870|text|我也有同样的问题，这对我很有效：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|173871|git+gc+--aggressive+--prune|code-block|syntax|javascript|173872|它花了一段时间，但完成后，所有的git操作开始更快地工作。|173873|之前失败的推送操作后来成功了，可能是因为它变得足够快，从而避免了一些与超时相关的问题。|173874|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

I had the same problem, and this worked for me:

<pre><code>git gc --aggressive --prune
</code></pre>

It took a while, but after it was done all git operations started working faster. 
The push operation that previously failed then succeeded, probably because it became fast enough to avoid some timeout related issue.

blocks|key|174834|text|在VMWare上使用arch发行版时，我遇到了这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|174835|添加|174836|IPQoS=throughput|offset|length|style|CODE|174837|到我的ssh配置(~/.ssh/+config+)为我做了这件事。|174838|entityMap^0|0|0|0|G|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@$F|Q|G|R|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

I had that issue when working with an arch distro on VMWare.

Adding

<code>IPQoS=throughput</code>

to my ssh config (~/.ssh/config) did the trick for me.

blocks|key|173891|text|因为我还没有看到这个答案:改变你的Wifi网络。我的应用程序阻塞了我，并给了我broken+pipe错误。在使用我的iPhone作为热点后，它工作得很完美！|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|173892|entityMap^0|13|B|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

Because I haven't seen this answer: Change your Wifi Network. Mine was blocking me and gave me the <code>broken pipe</code> error. After using my iPhone as a hotspot it worked perfectly!

blocks|key|174852|text|我不知道为什么，但我遇到了这个问题，当我从我的wifi网络的5G版本切换到另一个版本时，这个问题就消失了|type|unstyled|depth|inlineStyleRanges|entityRanges|data|174853|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I’m not sure why, but I was having this problem and it went away when I switched from the “5G” version of my wifi network to the other one

I'm trying to push for the first time a code to my git repository but i get the following error:

<blockquote>
<pre><code>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/&lt;...&gt;'
</code></pre>
</blockquote>

I tried to increase the http buffer size (<code>git config http.postBuffer 524288000</code>), I tried to <code>git repack</code>, but it did not work.

I was able to push a very similar size code to another repository (it was not working like this one, but after the <code>git repack</code> it did work). I'm trying to push it to bitbucket.

Any ideas?

Broken pipe when pushing to git repository

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋 

腾讯云代码助手

CODING DevOps

Cloud Studio

SDK中心

API中心

命令行工具

我正在尝试第一次将代码推送到我的git存储库，但我得到了以下错误：计数对象: 222026，完成。压缩对象: 100% (208850/208850)，完成。写入失败:pipe222026已损坏)错误: pack-objects死于信号13致命:远程端意外挂起错误:无法将一些引用推送到'ssh://git@bitbuc...

问推送到git仓库时管道断开
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问推送到git仓库时管道断开EN