Arquivos corrompidos no Git


8

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

Em qual sistema linux você fez as alterações?
Andres Jaan Tack

Eu estava usando janelas; agora estou no Linux e funciona bem
mnml

Respostas:


7

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.


ENORME, obrigado por esta resposta. O git-remove-trailing-garbage.py (seu link com o texto "escreveu um script" acima) salvou meu bacon quando me deparei com o mesmo bug do ecryptfs que você mencionou!
111111 Adam Monsen
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.