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

Git pull сбой с ошибкой заголовка пакета

git сбой при неудачной ошибке

remote: Counting objects: 146, done.
remote: fatal: unable to create thread: Resource temporarily unavailable
error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: protocol error: bad pack header

Любые идеи, как успешно вытащить?

4b9b3361

Ответ 1

Строки, начинающиеся с remote, выводятся из git, запущенных в удаленной системе. Ошибка:

fatal: unable to create thread: Resource temporarily unavailable

... настоятельно предполагает, что на сервере у вас закончилась нехватка памяти, что может произойти, если у вас есть:

  • Репозиторий с большим количеством больших файлов, который может вызвать переупаковку, чтобы занять много памяти.
  • Ограниченная виртуальная память - либо вообще, либо только для этой учетной записи из-за установки ulimit

Предложение здесь - ограничить объем памяти, который может упасть в упаковке, войдя в удаленную систему (как пользователь, который git работает как) и делает:

git config --global pack.windowMemory "100m"
git config --global pack.packSizeLimit "100m"
git config --global pack.threads "1" 

Ответ 2

Предупреждение: если вы видите эту ошибку с Git 2.19.1, это ожидается и задокументировано в git-for-windows/git выпуск 1839: " git gc падает на 33% подсчитывающих объектов" (который сообщает APPCRASH обоим для git gc, но также и для git pull), из-за мьютекса, используемого в "git pack-objects", который был неправильно инициализирован и вызвал " git repack " для выгрузки ядра в Windows.

Как уже упоминалось в выпуске:

Это влияет не только на gc. Я тоже выбрал вариант с pull:

$ git pull
remote: Enumerating objects: 3548, done.
error: git upload-pack: git-pack-objects died with error.
fatremote: aborting due to possible repository corruption on the remote side.
al: git uploadf-pack: aborting due to possible repository corruption on the remote side.
atal: protocol error: bad pack header

Это исправлено в Git 2.20 (Q4 2018).
См. Коммит 34204c8, коммит 9308f45, коммит ce498e0 (16 октября 2018 г.) Йоханнеса dscho (dscho).
(Объединено Junio C Hamano - gitster - в коммите 620b00e, 30 октября 2018 г.)

pack-objects (mingw): инициализировать мьютекс packing_data в правильном месте

В 9ac3f0e (pack-objects: исправление проблем с производительностью при упаковке больших дельт, 2018-07-22, Git v2.19.0-rc1) был представлен мьютекс, который используется для защиты вызова для установки размера дельты. Эта фиксация даже добавила код для его инициализации, но в неправильном месте: в init_threaded_search(), в то время как вызов oe_set_delta_size() (и, следовательно, к packing_data_lock()) может происходить в цепочке вызовов check_object() <- get_object_details() < - prepare_pack() <- cmd_pack_objects(), то есть задолго до того, prepare_pack() функция ll_find_deltas() вызывает ll_find_deltas() (который инициализирует многопоточный поиск).

Еще одним свидетельством того, что мьютекс был инициализирован в неправильном месте, является то, что функция для его инициализации живет во встроенном /, а код, использующий мьютекс, определен в заголовочном файле libgit.a.

Ответ 3

Обновление: этот ответ был предложением о внесении изменений в ответ Марк Лонгэйр, который теперь обновил свой ответ с правильным названием.

Фактически, pack.SizeLimit неверен, он pack.packSizeLimit.

Когда я добавил эту опцию, это сработало для меня:)

Мне пришлось установить его как в локальном, так и в удаленном репозиториях.

Ответ 4

В дополнение к ответу @Mark Longair:

Мне пришлось выполнить следующие команды, чтобы решить эту проблему:

git config --global pack.windowMemory "100m"
git config --global pack.packSizeLimit "100m"
git config --global pack.threads "1" 
git config --global pack.deltaCacheSize "512m"

Вы можете увидеть больше об этих командах в git git config.