Git возвращает ошибки «не удалось запустить repack» и «inflate return»

У меня возникла проблема с репозиторием Git, хранящимся в GitLab. Похоже, проблема с репозиторием затрагивает только этот конкретный репозиторий, поскольку все остальные проекты, размещенные в GitLab, работают нормально.

Кажется, я могу лично отправлять, извлекать и проверять ветки с помощью GitKraken, но когда я пытаюсь извлечь из Git Bash, я получаю следующее:

$ git pull
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
error: Could not read bb5a805503a3da247038200df7002f452a8781e9
fatal: bad tree object bb5a805503a3da247038200df7002f452a8781e9
error: failed to run repack

У всех людей, сотрудничающих со мной в этом же проекте, возникают схожие проблемы при попытке извлечения:

$ git pull
remote: Enumerating objects: 112, done.
remote: Counting objects: 100% (112/112), done.
remote: Compressing objects: 100% (102/102), done.
fatal: pack has bad object at offset 8105548: inflate returned -5
fatal: index-pack failed

И вот что мы все получаем при попытке клонировать репозиторий на новое место:

remote: Enumerating objects: 4364, done.
remote: Counting objects: 100% (4364/4364), done.
remote: Compressing objects: 100% (1622/1622), done.
fatal: pack has bad object at offset 56589977: inflate returned -5
fatal: index-pack failed

Вот что мы пробовали:

  • Проверено на нескольких компьютерах
  • Проверено несколькими пользователями

Я подозреваю, что, читая подобные вопросы, такие как этот, наш репозиторий сломано. Однако я не понимаю, почему мне кажется, что я могу работать с ним через GitKraken. С его графическим интерфейсом я успешно объединил две ветки и отправил последние коммиты на сервер.

У кого-нибудь есть объяснение, в чем может быть проблема?

Редактировать: попытка исправить репозиторий

Следуя этим инструкциям, содержащимся в опубликованной мной ссылке, а также предложенный ответом ниже, я выполнил команду git fsck --full, чтобы проверить состояние ссылок репозитория. То, что я нашел, не обнадеживает, так как кажется, что многие ссылки не работают.

Checking object directories: 100% (256/256), done.
Checking objects: 100% (3769/3769), done.
broken link from  commit f42ccacb8101ef49493aca18089378697490bb66
              to    tree e461e3cbe3221cd5ba7035222aa716dcabb63713
broken link from  commit 2fe8ac2b06d8e8f37b354c395f60a77f0ab1f9a9
              to    tree 93b9618cc159c1b18aba319e8f7e3e5e8f7b57df
broken link from  commit 16d23305969b3a40316618b952b2e5ff1ffedbf6
              to    tree 80c4012d9f3b3f51f17932dec80e740bc4e5a1d6
broken link from    tree 867941d734b41a5ce800dff6ea7dbfca30787e15
              to    tree bb5a805503a3da247038200df7002f452a8781e9
broken link from    tree e16211709ea4ce02a89bbe87d30a410dac65e372
              to    blob b6eb83a9e4f16fe49a0eb9bfea0bf6dfce9adcbc
broken link from    tree e16211709ea4ce02a89bbe87d30a410dac65e372
              to    blob a593c8f43faacf41bc93c98dbb347e673cd47f3f
broken link from    tree e16211709ea4ce02a89bbe87d30a410dac65e372
              to    blob 652245900beb49246e58f5c216dbcf161f727e2d
broken link from    tree e16211709ea4ce02a89bbe87d30a410dac65e372
              to    blob a7998441f7435126feb6b35e9b4b575bd193d6d2

за которым следует длинный список строк dangling commit и dangling blob с 8 экземплярами строк missing:

[...]
missing tree 80c4012d9f3b3f51f17932dec80e740bc4e5a1d6
[...]
missing blob a593c8f43faacf41bc93c98dbb347e673cd47f3f
[...]
[6 more]

Похоже, что ручное восстановление поврежденных файлов займет довольно много времени.

Правка №2: исправлено локальное хранилище

Я установил и запустил git-repair в своей локальной копии репозитория и фактически исправил это. Если я сейчас запущу git fsck --full, я увижу в ответ только "здоровые" сообщения. Больше никаких битых ссылок.

Однако, независимо от того, если я git push --force до origin, кажется, origin остается сломанным. Одно странное обновление заключается в том, что теперь я могу успешно использовать git clone, в то время как все мои коллеги по-прежнему не могут. Как это может быть?

И самое главное, есть ли способ запустить git-repair на origin?

Правка №3: создан новый источник

После локального исправления моего репозитория (и проверки того, что git fsck не дает отсутствующих ссылок) я переместил все соответствующие ветки в новый источник на GitLab. Я думал, что это будет все, но, к сожалению, проблема остается.

Я начинаю замечать, что мы, кажется, все можем clone из Ubuntu (используя Git Bash или GitKraken), но не в Windows 10 (ни используя Git Bash, ни GitKraken).

Читая сайт, я нашел вопрос о том, как могло случиться, что Git работал в Linux, но не в Windows. Там они объяснили, что это проблема, связанная с Git (но это было больше года назад). Есть ли смысл, что нечто подобное произошло? Я должен сказать, что отношусь к этому скептически, потому что другие репозитории, которые мы тестировали, отлично работают в Windows.

Редактирование №4: протестировано с более ранними версиями Git для Windows

Текущая версия 2.19. Я пробовал на 2.18 и 2.9 (последняя датируется 2016 годом), но получаю ту же ошибку.

Правка № 5: попытка локального клонирования прошла успешно

После предложения по проблеме GitHub я написал на git-for-windows, пробовал использовать git clone из копии репозитория на флешке. Это сработало. Похоже, проблема связана либо с Git+Windows+GitLab, либо с Git+Windows+SSH.


git gitlab git-pull gitkraken
person raggot    schedule 20.09.2018    source источник
comment
Если у вас есть доступ к серверу (т. е. он размещен самостоятельно), вы можете запустить gc и repack для удаления устаревших объектов. Или просто запустите там git-repair, но я предполагаю, что это не так. Как насчет перехода на новый пульт?   -  person msg    schedule 21.09.2018
comment
@msg, спасибо. Вы правильно догадались, и переход на новый пульт действительно был бы вариантом. Раздражает то, что связанный с проектом в Gitlab у нас также есть Wiki, и что нам придется проинструктировать всех (включая внешних сотрудников) о смене пульта. Я только что разместил тикет на Gitlab, спрашивая, можно ли исправить это онлайн.   -  person raggot    schedule 21.09.2018
comment
Если это просто вики, вы можете клонировать и отправить как и любой другой репозиторий   -  person msg    schedule 21.09.2018
comment
@msg, в конце концов я последовал твоему совету, но проклятие продолжается ... В твоей шляпе спрятан еще какой-нибудь кролик? Благодарить :)   -  person raggot    schedule 24.09.2018
comment
Извините, но не. После поиска ошибки все, что я могу вам сказать, это то, что ошибка, которую вы видите, представляет собой Z_BUF_ERROR, вызванную zlib, и, как предполагается, не является фатальной, также может быть ошибкой на gitaly, но это выходит за рамки моей области знаний. Надеюсь, разработчики решат вашу проблему. Удачи еще раз!   -  person msg    schedule 25.09.2018

Ответы (1)


arrow_upward
1
arrow_downward

Как указывает связанный ответ, большинство объектов в дереве различаются и сжимаются для экономии полосы пропускания и диска, создавая упомянутые файлы .pack.

Во время процесса извлечения клиент git обменивается с удаленным устройством списком ссылок и заголовков, поэтому удаленный пользователь может просмотреть их и вычислить, какие объекты необходимо отправить, исходя из того, что уже есть у клиента. Затем он создает пакеты и отправляет их клиенту. Это означает, что пакет, отправленный клиенту, может отличаться от другого пакета для одного и того же объекта.

Что касается причины, я не мог сказать, но правдоподобно, что ваше хранилище пропускает конфликтующий объект, хотя, поскольку разные клиенты выдают эту ошибку в одной и той же рабочей копии, это кажется маловероятным и выглядит так, как будто это может быть просто проблема с программным обеспечением, возможно, различия в zlib, используемом каждым клиентом.

Вы можете попробовать force-push свой репозиторий (не рекомендуется) или нажать на другой пульт в качестве крайней меры.

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

ОБНОВЛЕНИЕ: В качестве дополнения, -5 является Z_BUF_ERROR в zlib и согласно документации< /а>:

inflate() возвращает Z_OK, если был достигнут некоторый прогресс [...] Z_BUF_ERROR, если прогресс был невозможен или если в выходном буфере не хватило места при использовании Z_FINISH. Обратите внимание, что Z_BUF_ERROR не является фатальной, и inflate() может быть вызвана снова с большим количеством входных и выходных данных для продолжения распаковки. Если возвращается Z_DATA_ERROR[...]

Я лично думаю, что ошибка в программном обеспечении, а не в GitLab, но это предположение с моей стороны.

И предложение: если невозможно перевести всех разработчиков на Linux... Что насчет подсистемы Linux для W10?

person msg    schedule 20.09.2018
comment
Спасибо за отзыв. Я пытался force-push, но получаю только Everything up-to-date. Согласно руководству, которое вы упомянули по ссылке, я занят этим. Я обновлю свой вопрос, чтобы показать, что я получаю. - person raggot; 21.09.2018
comment
@raggot Я определенно рекомендую сделать новый клон / копию для операций восстановления. Помимо обычных fsck, gc и т. д., вы также можете попробовать перепаковать все это целиком, что не упоминалось в предыдущем руководстве. - person msg; 21.09.2018
comment
Спасибо. Я на самом деле не знал о repack. Я только что попробовал, но получил это сообщение об ошибке: error: Could not read bb5a805503a3da247038200df7002f452a8781e9 fatal: bad tree object bb5a805503a3da247038200df7002f452a8781e9 - person raggot; 21.09.2018
comment
Теперь мне удалось восстановить его локально (отредактированный вопрос с новыми деталями), но я до сих пор не знаю, как я могу получить то же самое для origin - person raggot; 21.09.2018
comment
Спасибо за обновленную информацию. Я ценю. Согласно предложению, мы хотели бы, чтобы в Windows все работало нормально, без заплаток. Во всяком случае, это проблема только с этим репо. Поскольку я также подозревал, что это может быть проблема с Git, я открыл проблему на GitHub. Я вернусь сюда, если найду решение - person raggot; 25.09.2018