Fichiers corrompus dans Git

J'ai récemment supprimé certains dossiers de mon historique git repos à l'aide de la commande suivante:

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

Malheureusement, je ne peux plus tirer de ce repos, voici le jeu d'erreurs que j'obtiens:

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

Une bonne âme a écrit un script pour le faire automatiquement (et de manière plus approfondie), mais le processus de récupération est essentiellement le suivant:

1. Examinez le fichier qui signale les ordures, avec hexdump.

   $ hexdump .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0
   

   Vous recherchez une partie du fichier où il y a une énorme plage de zéros. S'il existe plusieurs plages de ce type, j'ai eu de la chance (N = 2) en considérant uniquement le premier ensemble géant de zéros, même lorsqu'ils comprenaient de petites séries de données non nulles. Ce sont les "ordures" dont Git se plaint.

   ...
   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.
   

   Vous pouvez déterminer à partir de cela la taille réelle de l'objet. Ici, ce serait 0x504 ou 1 284 octets.

2. Faites une copie de sauvegarde de l'objet. Si vous choisissez le mauvais ensemble de zéros, vous pouvez réessayer avec un autre ensemble.

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

3. Tronquez le fichier à sa longueur appropriée.

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

L'objet corrompu doit maintenant être corrigé. En supposant qu'il était le seul, le clonage / pousser / tirer le référentiel devrait maintenant fonctionner comme prévu.

Citant mes sources, je pense avoir rencontré le même problème, mais dans mon cas en utilisant Ubuntu 10.4 (noyau 2.6.32-23-generic). Dans ce cas, il s'agit d'un bogue du système de fichiers qui n'a pas encore été retrouvé. Il y a un problème ouvert sur ecryptfs à ce sujet et également un thread usenet connexe . En chemin vers une solution, j'ai trouvé une réponse et un résumé pratiques sur StackOverflow. L' article lié était très intéressant, bien que j'aie finalement choisi une voie différente.