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

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

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

Изучите файл, сообщающий об мусоре, с помощью 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 байта.
Сделайте резервную копию объекта. Если вы выбрали неправильный набор нулей, вы можете повторить попытку с другим набором.
```
$ cp .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0 ~/old_4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0
```

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

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

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

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

— Андрес Яан Тэк
источник

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

— Адам Монсен