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

Question

git pull завершается с ошибкой

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

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

Answer 1

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

fatal: unable to create thread: Resource temporarily unavailable

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

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

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

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

Answer 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).
См. commit 34204c8 , коммит 9308f45 , коммит ce498e0 (16 октября 2018 г.) Йоханнес Шинделин (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() <- <code>get_object_details() <- <code>prepare_pack() <- <code>cmd_pack_objects(), то есть задолго до того, как функция prepare_pack() вызывает ll_find_deltas() (который инициализирует многопоточный поиск).

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

Answer 3

Дополнение ответа @ 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.

Answer 4

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

На самом деле, pack.SizeLimit неверно, это pack.packSizeLimit.

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

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