Arquivos corrompidos no Git

Question

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

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

Infelizmente, não consigo extrair mais desses 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

    

Answer 1

Alguma alma gentil escreveu um script para fazer isso automaticamente (e mais completamente), mas o processo de recuperação é basicamente isso:

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

   $ hexdump .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0
   

   Você está procurando uma parte do arquivo em que há um enorme intervalo de zeros. Se houver vários desses spans, tive boa sorte (N = 2) ao considerar apenas o primeiro conjunto gigante de zeros, mesmo quando eles incluíram pequenas séries de dados diferentes de zero. Esse é 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. Trunca o arquivo para o tamanho apropriado.

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

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

Citando minhas fontes, acredito ter experimentado o mesmo problema, mas no meu caso usando o Ubuntu 10.4 (kernel 2.6.32-23-generic). Neste caso, é um bug do sistema de arquivos que ainda não foi rastreado. Há um problema em aberto no ecryptfs sobre este assunto e também um tópico usenet relacionado . Ao longo do caminho para uma solução, encontrei uma resposta útil e resumo no StackOverflow. O artigo vinculado foi muito interessante , embora eu finalmente tenha sido diferente.