Comment gérer git gc fatal: mauvais objet refs / remotes / origin / HEAD error?

131

J'ai frappé au hasard aujourd'hui en essayant d'exécuter le ramasse-miettes Git :

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

Comment gérer cela?

git git-remote git-fetch git-gc Ryan
la source

Réponses:

163

Je ne comprends pas les ramifications de cela, mais comme suggéré dans ce fil , quand j'ai rencontré cela, je viens de le faire

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

(en le gardant juste au cas où) et ensuite

$ git gc

travaillé sans se plaindre; Je n'ai rencontré aucun problème.

petrelharp
la source
6
Cela a fonctionné pour moi et je pense que j'ai eu ce problème parce que j'ai changé la branche par défaut de masterà une autre appelée develop. Quelques jours avant de le changer de developà masteret j'ai supprimé l'ancienne branche par défautdevelop , mais dans mon répertoire de travail, le fichier .git/refs/remotes/origin/HEADpointait toujours vers refs/remotes/origin/developlequel n'existe plus. Dans cette situation, la suppression du fichier a fonctionné.
Stavarengo
4
git prunea fonctionné pour moi, un moyen de supprimer les données qui se sont accumulées dans Git mais qui ne sont référencées par rien d'utile.
Sven Malvik
Leur exécution a résolu mon problème:$ mv .git/refs/remotes/origin/HEAD /tmp $ git gc git prune
David Rauca
2
Je soupçonne que le meilleur moyen serait la réponse de @ WilQu ( stackoverflow.com/a/49944297/660339 ). Quelqu'un peut-il le confirmer?
Ivan Perez
supprimer ces fichiers du dossier .git, cela a git gcfonctionné pour moi
Vino
68

Le problème que j'ai rencontré (qui est le même problème que @Stavarengo mentionné dans ce commentaire ci-dessus) est que la branche distante par défaut ( developdans mon cas) avait été supprimée, mais était toujours référencée dans .git/refs/remotes/origin/HEAD.

L'ouverture .git/refs/remotes/origin/HEADdans mon éditeur a montré ceci:

ref: refs/remotes/origin/develop

Je l'ai soigneusement édité pour pointer vers ma nouvelle branche par défaut et tout allait bien:

ref: refs/remotes/origin/master

L'indice qui m'a informé était que la course à pied git prunemontrait cette erreur:

> git prune
warning: symbolic ref is dangling: refs/remotes/origin/HEAD
Trenton
la source
1
C'était aussi ma solution
Dan Carlstedt
1
C'était ma solution exacte. Notre équipe est récemment passée de l'utilisation d'un développement de branche par défaut à la maîtrise également
jmancherje
40

Après avoir vu la réponse de Trenton, j'ai regardé ma .git/refs/remotes/origin/HEADet j'ai vu qu'elle indiquait également une ancienne branche qui est maintenant supprimée.

Mais au lieu d'éditer le fichier moi-même, j'ai essayé la solution de Ryan:

git remote set-head origin --auto

Il a automatiquement défini le fichier sur la nouvelle branche et git gca bien fonctionné par la suite.

WilQu
la source
Oui, cela fonctionne pour moi - car j'étais exactement dans le même scénario. git remote set-head $REMOTE --autodans mon cas, $ REMOTE est l'alias distant, pas l '«origine» par défaut, car j'ai plusieurs télécommandes.
Devy
29

Je pensais que la solution était la suivante car cela semblait fonctionner, mais cela ne résout pas réellement le problème.

git remote set-head origin --auto
Ryan
la source
1
Il semble que cette commande m'a aidé à me débarrasser du même problème. Cependant, après cette commande, j'ai également utilisé git prune(comme cela était recommandé dans la première sortie de commande), donc je ne suis pas en mesure de dire exactement ce qui m'a aidé - premier, deuxième ou les deux.
Borys Pylhun
1
git remote set-head origin --autocorrigé mon fichier refs / remotes / origin / HEAD sans que j'aie à utilisergit prune
danio
J'ai rencontré cette erreur :, et j'ai error: Multiple remote HEAD branches. Please choose one explicitlydû utiliser git remote set-head origin mybranch(pendant que la branche 'mybranch' était à la caisse) pour que l'erreur disparaisse.
derekmx271
3
Le vote à la baisse parce que ce n'est pas une réponse complète et peut être trompeur.
Christian Vielma
9

On dirait que vos références symboliques pourraient être cassées ... Essayez de la remplacer par votre branche par défaut comme ceci: Par exemple, ma branche par défaut est master

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

Cela devrait le réparer.

Conal Trinitrotoluene Da Costa
la source
0

Si vous utilisez git worktrees, assurez-vous de faire un

git worktree prune

avant de courir

git gc

J'avais un arbre de travail corrompu et cela semblait faire l'affaire après avoir supprimé l'arbre de travail corrompu. git pruneen soi ne semblait pas fonctionner.

JeffP
la source
0

La cause de cela pour moi était de travailler dans un dossier compressé dans Windows. Lorsque le dossier était décompressé, il corrompait les fichiers du pack, provoquant d'autres problèmes étranges, tels que l'impossibilité d'élaguer les branches inexistantes.

Le seul correctif était d'effacer le répertoire de travail et de cloner à nouveau le (s) distant (s) du dépôt. Heureusement, je pouvais toujours pousser et tirer des mises à jour pour m'assurer que rien n'était perdu. Tout va bien maintenant.

Will Strohl
la source