Arquivos corrompidos no Git

Eu removi recentemente algumas pastas do meu histórico de repositórios git usando o seguinte comando:

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

Infelizmente não consigo mais extrair esses repositórios, este é o conjunto de erros que estou recebendo:

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

Alguma alma amável escreveu um script para fazer isso automaticamente (e mais detalhadamente), mas o processo de recuperação é basicamente o seguinte:

1. Examine o arquivo que relata lixo, com hexdump.

   $ hexdump .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0
   

   Você está procurando uma parte do arquivo em que há uma enorme extensão de zeros. Se houver vários desses períodos, tive sorte (N = 2) ao considerar apenas o primeiro conjunto gigante de zeros, mesmo quando incluíam pequenas execuções de dados diferentes de zero. Este é o "lixo" que o git está reclamando.

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

   Você pode determinar a partir disso o tamanho real do objeto. Aqui, seria 0x504 ou 1.284 bytes.

2. Faça uma cópia de backup do objeto. Caso você escolha o conjunto errado de zeros, tente novamente com um conjunto diferente.

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

3. Trunque o arquivo no tamanho apropriado.

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

O objeto corrompido agora deve ser corrigido. Supondo que fosse o único, clonar / empurrar / puxar o repositório agora deve funcionar como esperado.

Citando minhas fontes, acredito que experimentei o mesmo problema, mas no meu caso usando o Ubuntu 10.4 (kernel 2.6.32-23-genérico). Nesse caso, é um bug do sistema de arquivos que ainda não foi rastreado. Há um problema em aberto no ecryptfs sobre esse assunto e também um thread da usenet relacionado . No caminho para uma solução, encontrei uma resposta útil e um resumo no StackOverflow. O artigo vinculado foi muito interessante, apesar de eu ter seguido um caminho diferente.