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

Question

Недавно я удалил несколько папок из своей истории 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

Answer 1

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

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. Связанная статья была очень интересной, хотя в итоге я пошел другим путем.