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
Любые идеи, как успешно вытащить?
Ответы
Ответ 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
.