File danneggiati in Git

Di recente ho rimosso alcune cartelle dalla cronologia dei repository git usando il comando seguente:

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

Purtroppo non posso più estrarre da questi repository, questo è il set di errori che sto ottenendo:

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

Qualche anima gentile ha scritto una sceneggiatura per farlo automaticamente (e più accuratamente), ma il processo di recupero è sostanzialmente questo:

1. Esaminare il file che segnala immondizia, con hexdump.

   $ hexdump .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0
   

   Stai cercando una parte del file in cui c'è una grande quantità di zeri. Se ci sono più di tali intervalli, ho avuto buona fortuna (N = 2) quando ho considerato solo il primo gigantesco set di zeri, anche quando includevano piccole serie di dati diversi da zero. Questa è la "spazzatura" di cui Git si lamenta.

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

   È possibile determinare da questo la dimensione reale dell'oggetto. Qui, sarebbe 0x504 o 1.284 byte.

2. Crea una copia di backup dell'oggetto. Nel caso in cui si scelga un set di zeri errato, è possibile riprovare con un set diverso.

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

3. Tronca il file alla lunghezza appropriata.

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

L'oggetto corrotto ora dovrebbe essere corretto. Supponendo che fosse l'unico, clonare / spingere / estrarre il repository ora dovrebbe funzionare come previsto.

Citando le mie fonti, credo di aver riscontrato lo stesso problema, ma nel mio caso usando Ubuntu 10.4 (kernel 2.6.32-23-generico). In questo caso, si tratta di un bug del filesystem che non è stato ancora rintracciato. C'è un problema aperto su ecryptfs su questo argomento e anche un thread usenet correlato . Lungo la strada per una soluzione, ho trovato una risposta utile e un riepilogo su StackOverflow. L' articolo collegato è stato molto interessante, anche se alla fine sono andato in un modo diverso.