Alguma alma amável escreveu um script para fazer isso automaticamente (e mais detalhadamente), mas o processo de recuperação é basicamente o seguinte:
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.
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
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.