Поврежденные файлы в Git

8

Недавно я удалил некоторые папки из своей истории git-репозиторий с помощью следующей команды:

git filter-branch --index-filter 'git rm -r --cached var' -- --all

К сожалению, я больше не могу вытащить из этого репозитория. Это ошибка, которую я получаю:

git pull
remote: Counting objects: 3953, done.
remote: Compressing objects: 100% (2810/2810), done.
error: garbage at end of loose object '4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0'
fatal: object 4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0 is corrupted
fatal: index-pack failed
git repository file-corruption MNML
источник
В какой системе Linux вы внесли изменения?
Андрес Яан Тэк
Я использовал Windows; теперь я нахожусь на Linux, и это работает хорошо
mnml

Ответы:

7

Какая-то добрая душа написала скрипт, чтобы сделать это автоматически (и более тщательно), но процесс восстановления в основном такой:

  1. Изучите файл, сообщающий об мусоре, с помощью hexdump.

    $ hexdump .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0

    Вы ищете часть файла, где есть огромный диапазон нулей. Если таких диапазонов несколько, мне повезло (N = 2) при рассмотрении только первого гигантского набора нулей, даже если они включали небольшие серии ненулевых данных. Это "мусор", на который жалуется git.

    ...
0000500 0532 0302 0000 0000 0000 0000 0000 0000    # <-- Beginning here...
0000510 0000 0000 0000 0000 0000 0000 0000 0000
*
0001000             # ... almost 3kb of zeros.

    Из этого вы можете определить реальный размер объекта. Здесь это будет 0x504 или 1284 байта.

  2. Сделайте резервную копию объекта. Если вы выбрали неправильный набор нулей, вы можете повторить попытку с другим набором.

    $ cp .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0 ~/old_4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0

  3. Обрежьте файл до нужной длины.

    $ truncate -s 1284 .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0

Поврежденный объект теперь должен быть исправлен. Предполагая, что это было единственное, клонирование / перемещение / извлечение репозитория теперь должно работать как ожидалось.

Ссылаясь на мои источники, я думаю, что столкнулся с той же проблемой, но в моем случае я использовал Ubuntu 10.4 (ядро 2.6.32-23-generic). В данном случае это ошибка файловой системы, которая еще не была обнаружена. Существует открытая проблема на ecryptfs на эту тему, а также связанный поток usenet . На пути к решению я нашел удобный ответ и резюме по StackOverflow. Связана статья была очень интересной, хотя я в конечном счете , пошел другой путь.

Андрес Яан Тэк
источник
Огромное спасибо за этот ответ. git-remove-trailing-garbage.py (ваша ссылка с текстом «написал скрипт» выше) сохранил мой бекон, когда я столкнулся с той же ошибкой ecryptfs, которую вы упомянули!
Адам Монсен