Ошибка извлечения GIT — удаленный объект поврежден

$ git pull

remote: fatal: object 21f3981dd35fccd28febabd96f27241eea856c50 is corrupted
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

Есть идеи, почему это не работает?
Когда я запускаю git --bare fsck-objects --full, я вижу только оборванные ссылки, но не вижу неработающих ссылок. Также git gc никак не помог. Когда я повторно клонирую или извлекаю данные из другого клона, я не вижу этой ошибки.


git git-pull git-fetch
person Senthil A Kumar    schedule 13.11.2010    source источник
comment
Вы используете git fsck на удаленном компьютере? Если нет, это не имеет отношения к ошибке - это объект на удаленной стороне, и fsck в вашем репо проверяет объекты в вашем репо. У него нет возможности увидеть те, что в пульте.   -  person Cascabel    schedule 13.11.2010
comment
да, я запускаю git fsck в удаленном голом репозитории.   -  person Senthil A Kumar    schedule 13.11.2010
comment
Попробуйте git fsck --full 21f3981 ; git repack на пульте. Если это произойдет снова, проверьте брандмауэр.   -  person J-16 SDiZ    schedule 13.11.2010
comment
Большое спасибо Jefromi & J-16SDiZ за информацию, к сожалению, я не могу воспроизвести ошибку, на этот раз сработало вытягивание, и я ничего не сделал. Попробую вышеуказанные шаги, когда я снова получу эту ошибку.   -  person Senthil A Kumar    schedule 16.11.2010
comment
У меня была такая же проблема с битбакетом. git fsck делает свое дело. Спасибо.   -  person Andy    schedule 29.02.2012
comment
Я думаю, что комментарий J-16 следует принять как ответ :-)   -  person godzillante    schedule 14.05.2014

Ответы (7)


arrow_upward
30
arrow_downward

Как сказал Джулиан, см. https://confluence.atlassian.com/display/FISHKB/Git+indexing+fails+due+to+bad+pack+header

Это действительно может быть проблема с памятью, и чтобы убедиться, что мы не потеряем решение, вот оно:

git config --global pack.windowMemory "100m"
git config --global pack.SizeLimit "100m" 
git config --global pack.threads "1"
person cazcade_neil    schedule 29.11.2013
comment
Если ваш сервер использует интеллектуальный протокол http, возможно, вы не сможете установить глобальную конфигурацию для процесса. Вместо этого cd в каталог самого репозитория git и запускайте те же команды без --global. - person yig; 08.07.2015
comment
Упомянутое здесь решение atlassan сработало для меня, просто ssh'd, выполнил 3 команды, вышел и добился успеха с первой попытки. - person blamb; 31.01.2017

arrow_upward
17
arrow_downward

Добавление git config --global pack.window "0" сработало для меня... вместе со следующим

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

Причина:

Git clone сжимает данные при клонировании репозитория

Он сжимает данные в памяти сервера перед получением данных/файлов.

Если на сервере недостаточно памяти, вы получите указанную выше ошибку при упаковке объектов.

Вы можете решить эту проблему, заставив git клонировать репозиторий без упаковки объектов на сервере следующим образом.

git config --global pack.window "0"

person logan    schedule 01.02.2015
comment
Это конфигурация для клиента или сервера? - person Aaron Wang; 11.07.2016
comment
@AaronWang: это для клиентской машины, на которой вы клонировали свой репозиторий !! - person logan; 17.08.2016

arrow_upward
13
arrow_downward

Похоже ответ в комментариях: git fsck

person robrich    schedule 08.05.2012
comment
Гораздо более вероятно, что на сервере закончилась оперативная память, создающая файлы пакетов. - person Jon Watte; 25.04.2016

arrow_upward
6
arrow_downward

Только что получил эту ошибку и потратил полдня на все, что описано в посте: fsck, repack, gc, настройка опций памяти.

Также последовал этот пост: http://git.kernel.org/cgit/git/git.git/tree/Documentation/howto/recover-corrupted-blob-object.txt?id=HEAD

Но, в конце концов, это было так же просто, как найти поврежденный объект (в данном случае 21f3981dd35fccd28febabd96f27241eea856c50) в голом репозитории и заменить его неповрежденной версией (которую можно найти в папке .git любого из локальных репозиториев, которые вытащили /cloned из голого репозитория.)

person Shiva    schedule 09.01.2014

arrow_upward
5
arrow_downward

в клиенте попробуй сделать так:

git config --global pack.windowMemory "100m"
git config --global pack.SizeLimit "100m" 
git config --global pack.threads "1"
git config --global pack.window "0"

или на сервере git попробуйте следующее: изменить: /home/git/repositories/***.git/config, добавить ниже:

[pack]
         window = 0
person litian.zhuang    schedule 19.06.2017
comment
Это решило проблему и для меня, т.е. изменение конфигурации на стороне сервера. - person Sqripter; 18.01.2018

arrow_upward
1
arrow_downward

Это решит проблему для меня, и надеюсь, что это поможет кому-то еще. :) https://confluence.atlassian.com/display/FISHKB/Git+indexing+fails+due+to+bad+pack+header

person Julian    schedule 20.11.2013
comment
Обратите внимание, что ответы только по ссылкам не рекомендуются, ответы SO должны быть конечной точкой поиска. для решения (по сравнению с еще одной остановкой ссылок, которые со временем устаревают). Пожалуйста, рассмотрите возможность добавления здесь отдельного синопсиса, оставив ссылку в качестве ссылки. - person kleopatra; 20.11.2013

arrow_upward
0
arrow_downward

Для меня это произошло потому, что на моем удаленном сервере, на котором размещался репозиторий git, был поврежден объект/файл. Когда я попытался перепаковать, у него закончилась память. Я обновил память своего экземпляра, а затем снова подключился по ssh и запустил

git gc

Вот ссылка на документацию:

https://git-scm.com/book/uz/v2/Git-Internals-Packfiles

person zeros-and-ones    schedule 12.11.2016