Tente os seguintes comandos primeiro (execute novamente se necessário):
$ git fsck --full
$ git gc
$ git gc --prune=today
$ git fetch --all
$ git pull --rebase
E então você ainda tem problemas, tente pode:
remova todos os objetos corrompidos, por exemplo
fatal: loose object 91c5...51e5 (stored in .git/objects/06/91c5...51e5) is corrupt
$ rm -v .git/objects/06/91c5...51e5
remova todos os objetos vazios, por exemplo
error: object file .git/objects/06/91c5...51e5 is empty
$ find .git/objects/ -size 0 -exec rm -vf "{}" \;
verifique uma mensagem de "link quebrado" ao:
git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
Isso informa de qual arquivo veio o blob corrompido!
para recuperar o arquivo, você pode ter muita sorte, e pode ser a versão que você já verificou em sua árvore de trabalho:
git hash-object -w my-magic-file
novamente, e se ele mostrar o SHA1 ausente (4b945 ..), está tudo pronto!
presumindo que era alguma versão mais antiga que estava quebrada, a maneira mais fácil de fazer isso é:
git log --raw --all --full-history -- subdirectory/my-magic-file
e isso irá mostrar-lhe todo o log desse arquivo (por favor, perceba que a árvore que você tinha pode não ser a árvore de nível superior, então você precisa descobrir em qual subdiretório ele estava sozinho), então agora você pode recriar o objeto ausente com objeto hash novamente.
para obter uma lista de todas as referências com commits, árvores ou blobs ausentes:
$ git for-each-ref --format='%(refname)' | while read ref; do git rev-list --objects $ref >/dev/null || echo "in $ref"; done
Pode não ser possível remover alguns desses refs usando os comandos branch -d ou tag -d regulares, já que eles morrerão se o git perceber a corrupção. Portanto, use o comando de encanamento git update-ref -d $ ref. Note que no caso de branches locais, este comando pode deixar a configuração de branch obsoleta para trás em .git / config. Ele pode ser excluído manualmente (procure a seção [branch "$ ref"]).
Depois que todos os refs estiverem limpos, ainda pode haver commits quebrados no reflog. Você pode limpar todos os reflogs usando git reflog expire --expire = now --all. Se você não quiser perder todos os seus reflogs, você pode pesquisar os refs individuais por reflogs quebrados:
$ (echo HEAD; git for-each-ref --format='%(refname)') | while read ref; do git rev-list -g --objects $ref >/dev/null || echo "in $ref"; done
(Observe a opção -g adicionada ao git rev-list.) Então, use git reflog expire --expire = now $ ref em cada um deles. Quando todos os refs e reflogs quebrados desaparecerem, execute git fsck --full para verificar se o repositório está limpo. Objetos pendentes estão ok.
Abaixo você pode encontrar o uso avançado de comandos que potencialmente podem causar perda de seus dados em seu repositório git se não forem usados com sabedoria, então faça um backup antes de acidentalmente causar mais danos ao seu git. Experimente por sua própria conta e risco se você sabe o que está fazendo.
Para puxar o branch atual em cima do branch upstream após a busca:
$ git pull --rebase
Você também pode tentar verificar o novo branch e excluir o antigo:
$ git checkout -b new_master origin/master
Para encontrar o objeto corrompido no git para remoção, tente o seguinte comando:
while [ true ]; do f=`git fsck --full 2>&1|awk '{print $3}'|sed -r 's/(^..)(.*)/objects\/\1\/\2/'`; if [ ! -f "$f" ]; then break; fi; echo delete $f; rm -f "$f"; done
Para OSX, use em sed -Evez de sed -r.
Outra ideia é descompactar todos os objetos de arquivos de pacote para regenerar todos os objetos dentro de .git / objects, então tente executar os seguintes comandos dentro de seu repositório:
$ cp -fr .git/objects/pack .git/objects/pack.bak
$ for i in .git/objects/pack.bak/*.pack; do git unpack-objects -r < $i; done
$ rm -frv .git/objects/pack.bak
Se acima não ajudar, você pode tentar rsync ou copiar os objetos git de outro repo, por exemplo
$ rsync -varu git_server:/path/to/git/.git local_git_repo/
$ rsync -varu /local/path/to/other-working/git/.git local_git_repo/
$ cp -frv ../other_repo/.git/objects .git/objects
Para consertar o branch quebrado ao tentar finalizar a compra da seguinte maneira:
$ git checkout -f master
fatal: unable to read tree 5ace24d474a9535ddd5e6a6c6a1ef480aecf2625
Tente removê-lo e check-out do upstream novamente:
$ git branch -D master
$ git checkout -b master github/master
No caso de o git colocar você no estado desanexado, verifique o mastere mescle nele o branch desanexado.
Outra ideia é realocar o mestre existente recursivamente:
$ git reset HEAD --hard
$ git rebase -s recursive -X theirs origin/master
Veja também:
.gitpasta, é claro) para o repo recém-clonado ... e o fezgit statusno novo repo ... git detecta corretamente todas as alterações afetadas em meus arquivos e posso começar meu trabalho novamente.