Archivos corruptos en Git

Recientemente he eliminado algunas carpetas de mi historial de repositorios de git usando el siguiente comando:

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

Desafortunadamente no puedo extraer más de estos repositorios, este es el conjunto de errores que obtengo:

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

Algún tipo de alma escribió un script para hacer esto automáticamente (y más a fondo), pero el proceso de recuperación es básicamente el siguiente:

1. Examine el archivo que informa basura, con hexdump.

   $ hexdump .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0
   

   Estás buscando una parte del archivo donde hay una gran cantidad de ceros. Si hay varios intervalos de este tipo, he tenido buena suerte (N = 2) al considerar solo el primer conjunto gigante de ceros, incluso cuando incluían pequeñas series de datos distintos de cero. Esta es la "basura" de la que se queja 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.
   

   Puede determinar a partir de esto el tamaño real del objeto. Aquí, sería 0x504 o 1,284 bytes.

2. Haga una copia de seguridad del objeto. En caso de que elija el conjunto de ceros incorrecto, puede volver a intentarlo con un conjunto diferente.

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

3. Truncar el archivo a su longitud adecuada.

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

El objeto corrupto ahora debe ser reparado. Suponiendo que fuera el único, clonar / empujar / tirar del repositorio ahora debería funcionar como se esperaba.

Citando mis fuentes, creo que he experimentado el mismo problema, pero en mi caso usando Ubuntu 10.4 (kernel 2.6.32-23-generic). En este caso, es un error del sistema de archivos que aún no se ha rastreado. Hay un problema abierto en ecryptfs sobre este tema y también un hilo relacionado de Usenet . En el camino hacia una solución, encontré una respuesta útil y un resumen sobre StackOverflow. El artículo vinculado fue muy interesante, aunque finalmente tomé un camino diferente.