Пошкоджені файли в Git

Нещодавно я видалив декілька папок із своєї історії git repos за допомогою наступної команди:

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

Якась душа написала сценарій, щоб зробити це автоматично (і більш ретельно), але процес відновлення в основному такий:

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 або 1 284 байт.

2. Зробіть резервну копію об’єкта. Якщо ви вибрали неправильний набір нулів, ви можете спробувати ще раз з іншим набором.

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

3. Скоротіть файл до відповідної довжини.

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

Корумпований об’єкт тепер має бути виправлений. Якщо припустити, що це єдиний, клонування / виштовхування / витягування сховища зараз має працювати як очікувалося.

Посилаючись на свої джерела, я вважаю, що у мене виникла та сама проблема, але в моєму випадку використовую Ubuntu 10.4 (ядро 2.6.32-23-generic). У цьому випадку це помилка файлової системи, яку ще не було відстежено. Існує відкрита проблема щодо шифрів на цю тему, а також пов'язана нитка Usenet . По дорозі до рішення я знайшов зручну відповідь та резюме на StackOverflow. Пов'язана стаття була дуже цікавою, хоча я в кінцевому рахунку , пішов інший шлях.