web-dev-qa-db-ja.com

gitリポジトリにプッシュするときにパイプが壊れる

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://[email protected]/<...>'

HTTPバッファーサイズ（git config http.postBuffer 524288000）、 やってみました git repack、しかしそれは機能しませんでした。

私は非常に似たサイズのコードを別のリポジトリにプッシュすることができました（これはこのリポジトリのようには動作しませんでしたが、git repackうまくいきました。私はそれをbitbucketにプッシュしようとしています。

何か案は？

gitpushbitbucketbroken-pipe
30
Deadlock

簡単な解決策は、HTTPポストバッファーサイズを増やして、より大きなチャンクをリモートリポジトリにプッシュできるようにすることです。それを行うには、単に次を入力します。

git config http.postBuffer 52428800

数値はバイト単位であるため、この場合は50MBに設定しています。デフォルトは1MBです。

29
Milan Saha

VMWareのArchディストリビューションで作業しているときに、この問題が発生しました。

追加中

IPQoS=throughput

私のssh構成（〜/ .ssh/config）に私のためのトリックをしました。

4
TsTiX

私は同じ問題を抱えていましたが、これは私のために働いた：

git gc --aggressive --Prune

しばらく時間がかかりましたが、それが完了すると、すべてのgit操作がより速く動作し始めました。
。

1
Joe

ギガバイトのデータをgithubリポジトリにアップロードするときに同じ問題に遭遇しました。このサイズのデータ​​では、HTTPバッファーサイズを増やしても機能しませんでした。 git自体の問題なのか、githubサーバーの問題なのかわかりません。とにかく、この問題を処理するシェルスクリプトを作成しました。このスクリプトは、100 MB未満のデータごとに、現在のディレクトリのファイルを段階的にアップロードします。私にとってはうまく機能しています。時間がかかりますが、スクリーンを取り外して一晩待つだけです。

シェルスクリプトは次のとおりです。 https://Gist.github.com/sekika/570495bd0627acff6c836de18e78f6fd

0
seki

パックファイルが破損している（つまり、パックオブジェクトが失敗する）場合、プッシュは（postBufferを増やしても）フリーズする可能性があることに注意してください。

これはgit 2.9（2016年6月）で修正されます

commit c4b2751 、 commit df85757 、 commit 3e8b06d 、 commit c792d7b 、 commit 739cf49 を参照してください（2016年4月19日）by ジェフ・キング（peff） .
（ 浜野邦夫-gitster- in commit d689301 、2016年4月29日）

「git Push "デッドロックされた多数のrefをプッシュしようとする破損リポジトリから。これらのref更新の拒否通知を中継するスレッドは、受信側のメインスレッドがプッシュが失敗したことを通知した後、メインスレッドへの書き込みでブロックされますそして、これらの通知を読んで失敗を返さないことにします。

Commit 739cf49 にすべての詳細が含まれています。

send-pack：非同期プロセスを完了する前にdemuxパイプを閉じます

これにより、破損したレポから大量の参照をプッシュする際のクライアント側のデッドロックが修正されます。

0
VonC