Como lidar com git gc fatal: bad objeto refs / remotes / origin / erro HEAD?

131

Eu bati isso aleatoriamente hoje ao tentar executar a coleta de lixo do Git :

$ git gc
fatal: bad object refs/remotes/origin/HEAD
error: failed to run repack

Como faço para lidar com isso?

— Ryan
fonte

161

Eu não entendo as ramificações disso, mas como sugerido neste tópico , quando eu encontrei isso, eu apenas fiz

$ mv .git/refs/remotes/origin/HEAD /tmp

(mantendo-o por precaução) e depois

$ git gc

trabalhou sem reclamar; Não tive problemas.

— petrelharp
fonte

6

Funcionou para mim e acho que entrei nesse problema porque alterei o ramo padrão de masterpara outro chamado develop. Dias antes de eu voltar a alterar de e developpara excluir a ramificação padrão antiga , mas no meu diretório de trabalho, o arquivo ainda estava apontando para o qual não existe mais. Nessa situação, a remoção do arquivo funcionou. masterdevelop.git/refs/remotes/origin/HEADrefs/remotes/origin/develop

— Stavarengo 4/17/17

4

git prunefuncionou para mim, uma maneira de excluir dados acumulados no Git, mas que não estão sendo referenciados por nada útil.

— Sven Malvik

Executá-los resolveu o meu problema:$ mv .git/refs/remotes/origin/HEAD /tmp $ git gc git prune

— David Rauca 19/07/19

2

Eu suspeito que a melhor maneira seria a resposta de @ WilQu ( stackoverflow.com/a/49944297/660339 ). alguém pode confirmar isso?

— Ivan Perez

removendo esses arquivos da pasta .git, do que git gcfuncionou para mim #

— Vino

68

O problema que eu encontrei (que é o mesmo problema que o @Stavarengo mencionou neste comentário acima) é que o ramo remoto padrão ( developno meu caso) foi excluído, mas ainda foi mencionado em .git/refs/remotes/origin/HEAD.

A abertura .git/refs/remotes/origin/HEADno meu editor mostrou isso:

ref: refs/remotes/origin/develop

Eu o editei cuidadosamente para apontar para o meu novo ramo padrão e tudo estava bem:

ref: refs/remotes/origin/master

A pista que me deu a dica foi que a corrida git prunemostrou este erro:

> git prune
warning: symbolic ref is dangling: refs/remotes/origin/HEAD

— Trenton
fonte

1

Essa foi a minha correção bem

— Dan Carlstedt

1

Esta foi a minha solução exata. Nossa equipe mudou recentemente de usar um desenvolvimento padrão da ramificação para dominar também

— jmancherje 27/11/18

40

Depois de ver a resposta de Trenton, olhei para a minha .git/refs/remotes/origin/HEADe vi que ela também estava apontando para um ramo antigo que agora foi excluído.

Mas, em vez de editar o arquivo, tentei a solução de Ryan:

git remote set-head origin --auto

Ele definiu automaticamente o arquivo para a nova ramificação e git gcfuncionou bem depois disso.

— WilQu
fonte

Sim, isso funciona para mim - como eu estava exatamente no mesmo cenário. git remote set-head $REMOTE --autono meu caso, $ REMOTE é o alias remoto, não a "origem" padrão, porque tenho vários controles remotos configurados.

— Devy

29

Eu pensei que a solução era a seguinte, pois isso parecia funcionar, mas acaba não resolvendo o problema.

git remote set-head origin --auto

— Ryan
fonte

1

Parece que esse comando me ajudou a me livrar do mesmo problema. No entanto, após esse comando, eu também usei git prune(como recomendado na saída do primeiro comando), portanto não sou capaz de dizer exatamente o que me ajudou - primeiro, segundo ou ambos.

— precisa saber é o seguinte

1

git remote set-head origin --autofixa o meu refs / remotes / origem arquivo / HEAD sem me ter de usargit prune

— Danio

Eu encontrei este erro :, error: Multiple remote HEAD branches. Please choose one explicitlye tive que usar git remote set-head origin mybranch(enquanto o ramo 'mybranch' estava fazendo checkout) para obter o erro.

— Drekmx271

3

Voto negativo, porque não é uma resposta completa e pode ser enganosa.

— Christian Vielma

9

Parece que suas referências simbólicas podem estar quebradas ... Tente substituí-lo por sua ramificação padrão da seguinte maneira: Por exemplo, minha ramificação padrão é master

$ git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/master
$ git fetch --prune
$ git gc

Isso deve consertar.

— Conal Trinitrotolueno Da Costa
fonte

0

Se você estiver usando workstes git, verifique se está fazendo um

git worktree prune

antes de correr

git gc

Eu tinha uma árvore de trabalho corrompida e isso parecia funcionar depois de remover a árvore de trabalho corrompida. git prunepor si só não parecia funcionar.

— JeffP
fonte

0

A causa disso para mim estava trabalhando em uma pasta compactada no Windows. Quando a pasta foi descompactada, ela corrompeu os arquivos do pacote, causando outros problemas estranhos, como não poder remover ramificações inexistentes.

A única correção foi limpar o diretório de trabalho e clonar o (s) controle remoto (s) repo novamente. Felizmente, eu ainda podia enviar e receber atualizações para garantir que nada foi perdido. Tudo está bem agora.

— Will Strohl
fonte