Подтвердить что ты не робот

Сломанная трубка при нажатии на 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 он действительно работал). Я пытаюсь подтолкнуть его к битбакету.

Любые идеи?

4b9b3361

ОТВЕТЫ

Ответ 1

Простым решением является увеличение размера буфера HTTP-почты, позволяющего увеличить количество блоков до удаленного репо. Для этого просто введите:

git config http.postBuffer 52428800

Число находится в байтах, поэтому в этом случае я установил его в 50 МБ. Значение по умолчанию - 1 МБ.

Ответ 2

Обратите внимание, что push все еще может зависнуть (даже при увеличении postBuffer), когда его файлы пакета повреждены (например, пакеты-объекты не работают)

Это будет зафиксировано в git 2.9 (июнь 2016 г.)

См. commit c4b2751, commit df85757, commit 3e8b06d, совершить c792d7b, совершить 739cf49 (19 апреля 2016 года) Джефф Кинг (peff).
(слияние Юнио С Хамано - gitster - в commit d689301, 29 апреля 2016 г.

"git push" из коррумпированного репозитория, который пытается заблокировать большое количество refs; поток для ретрансляции уведомлений об отказе для этих обновлений ref блокируется при записи их в основной поток, после того, как основной поток на принимающей стороне замечает, что нажатие не выполнено, и решает не читать эти уведомления и возвращать сбой.

Commit 739cf49 содержит все подробности.

send-pack: закрыть демпферную трубку перед завершением процесса асинхронного процесса

Это фиксирует тупик на стороне клиента при нажатии большого количества ссылок на поврежденное репо.

Ответ 3

Я столкнулся с той же проблемой при загрузке моих гигабайт данных в репозиторий github. Увеличение размера буфера HTTP для этого размера данных не помогло. Я не уверен, что это проблема самого git или сервера github. В любом случае я создал оболочку script для решения этой проблемы, которая постепенно загружает файлы в текущий каталог, на каждом шаге менее 100 МБ данных. Он отлично работает для меня. Это занимает время, но я могу просто отключить экран и подождать ночь.

Вот оболочка script: https://gist.github.com/sekika/570495bd0627acff6c836de18e78f6fd

Ответ 4

У меня была такая же проблема, и это сработало для меня:

git gc --aggressive --prune

Это заняло некоторое время, но после того, как это было сделано, все операции git начали работать быстрее.
Операция push, которая ранее не удалась, завершилась успешно, возможно потому, что она стала достаточно быстрой, чтобы избежать проблемы, связанной с тайм-аутом.

Ответ 5

У меня была эта проблема при работе с дистрибутивом Arch на VMWare.

Добавление

IPQoS=throughput

мой конфиг ssh (~/.ssh/config) помог мне.