Uszkodzone pliki w Git

Niedawno usunąłem niektóre foldery z historii repozytoriów git za pomocą następującego polecenia:

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

Niestety nie mogę już pobierać z tych repozytoriów, oto zestaw błędów, który otrzymuję:

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

Jakaś dobra dusza napisała skrypt, aby to zrobić automatycznie (i dokładniej), ale proces odzyskiwania jest w zasadzie taki:

1. Sprawdź plik zgłaszający śmieci za pomocą zrzutu heksowego.

   $ hexdump .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0
   

   Szukasz części pliku, w której istnieje duża rozpiętość zer. Jeśli istnieje wiele takich rozpiętości, miałem szczęście (N = 2), rozważając tylko pierwszy gigantyczny zestaw zer, nawet jeśli zawierały małe serie niezerowych danych. Na to „śmieci” narzeka 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.
   

   Na tej podstawie możesz określić rzeczywisty rozmiar obiektu. W tym przypadku będzie to 0x504 lub 1284 bajtów.

2. Wykonaj kopię zapasową obiektu. Jeśli wybierzesz zły zestaw zer, możesz spróbować ponownie z innym zestawem.

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

3. Obetnij plik do odpowiedniej długości.

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

Uszkodzony obiekt powinien teraz zostać naprawiony. Zakładając, że był to jedyny, klonowanie / pchanie / wyciąganie repozytorium powinno teraz działać zgodnie z oczekiwaniami.

Powołując się na moje źródła, wydaje mi się, że napotkałem ten sam problem, ale w moim przypadku korzystam z Ubuntu 10.4 (jądro 2.6.32-23-generic). W tym przypadku jest to błąd systemu plików, który nie został jeszcze wyśledzony. W tym temacie istnieje otwarty problem dotyczący ecryptfs, a także powiązany wątek usenet . W drodze do rozwiązania znalazłem przydatną odpowiedź i podsumowanie na StackOverflow. Powiązany artykuł był bardzo ciekawy, choć ostatecznie poszedł inną drogą.