Jak poradzić sobie z błędem git gc fatal: bad object refs / remotes / origin / HEAD error?

131

Przypadkowo trafiłem w to dzisiaj, próbując uruchomić Git garbage collect :

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

Jak sobie z tym radzę?

— Ryan
źródło

163

Nie rozumiem konsekwencji tego, ale jak sugerowano w tym wątku , kiedy to spotkałem, właśnie to zrobiłem

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

(trzymanie go na wszelki wypadek), a potem

$ git gc

pracował bez narzekania; Nie napotkałem żadnych problemów.

— petrelharp
źródło

6

U mnie zadziałało i myślę, że wpadłem w ten problem, ponieważ zmieniłem domyślną gałąź z masterna inną o nazwie develop. Kilka dni wcześniej zmieniłem go z powrotem z developna masteri usunąłem starą domyślną gałąźdevelop , ale w moim katalogu roboczym .git/refs/remotes/origin/HEADnadal wskazywał plik, refs/remotes/origin/developktóry już nie istnieje. W tej sytuacji usunięcie pliku zadziałało.

— Stavarengo

4

git prunezadziałał dla mnie sposób na usunięcie danych zgromadzonych w Git, ale nie ma do nich żadnych przydatnych odniesień.

— Sven Malvik

Wykonanie ich rozwiązało mój problem:$ mv .git/refs/remotes/origin/HEAD /tmp $ git gc git prune

— David Rauca

2

Podejrzewam, że najlepszym sposobem byłaby odpowiedź @ WilQu ( stackoverflow.com/a/49944297/660339 ). Czy ktoś może to potwierdzić?

— Ivan Perez

usunięcie tego pliku z folderu .git, niż git gcdziałało dla mnie

— Vino

68

Problem, na który natknąłem się (który jest tym samym problemem, o którym @Stavarengo wspomniał w powyższym komentarzu ) polega na tym, że domyślna zdalna gałąź ( developw moim przypadku) została usunięta, ale nadal była przywoływana w .git/refs/remotes/origin/HEAD.

Otwarcie .git/refs/remotes/origin/HEADw moim edytorze pokazało to:

ref: refs/remotes/origin/develop

I dokładnie edytowane go do punktu, w moim nowym domyślnym gałęzi i wszystko było dobrze:

ref: refs/remotes/origin/master

Wskazówka, która dała mi wskazówkę, była taka, że uruchomienie git prunepokazało ten błąd:

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

— Trenton
źródło

1

To też była moja poprawka

— Dan Carlstedt

1

To było moje dokładne rozwiązanie. Nasz zespół niedawno przeszedł z używania domyślnej gałęzi develop na master

— jmancherje

40

Po zobaczeniu odpowiedzi Trentona spojrzałem na mój .git/refs/remotes/origin/HEADi zobaczyłem, że wskazuje on również na starą gałąź, która jest teraz usunięta.

Ale zamiast samodzielnie edytować plik, wypróbowałem rozwiązanie Ryana:

git remote set-head origin --auto

Automatycznie ustawił plik na nową gałąź i git gcpo tym działał dobrze.

— WilQu
źródło

Tak, to działa dla mnie - ponieważ byłem w dokładnie tym samym scenariuszu. git remote set-head $REMOTE --autow moim przypadku $ REMOTE jest zdalnym aliasem, a nie domyślnym „źródłem”, ponieważ mam konfigurację wielu pilotów.

— Devy

29

Myślałem, że rozwiązanie jest następujące, ponieważ wydawało się, że działa, ale okazuje się, że w rzeczywistości nie rozwiązuje problemu.

git remote set-head origin --auto

— Ryan
źródło

1

Wygląda na to, że to polecenie pomogło mi pozbyć się tego samego problemu. Jednak po tym poleceniu również użyłem git prune(zgodnie z zaleceniami w wynikach pierwszego polecenia), więc nie jestem w stanie dokładnie powiedzieć, co mi pomogło - pierwsze, drugie lub oba.

— Borys Pylhun

1

git remote set-head origin --autonaprawiono moje referencje / piloty / pochodzenie / plik HEAD bez konieczności używaniagit prune

— danio

Napotkałem ten błąd :, error: Multiple remote HEAD branches. Please choose one explicitlyi musiałem użyć git remote set-head origin mybranch(podczas gdy gałąź „mybranch” była wyrejestrowana), aby błąd zniknął.

— derekmx271

3

Głosowanie w dół, ponieważ nie jest pełną odpowiedzią i może wprowadzać w błąd.

— Christian Vielma

9

Wygląda na to, że twoje symboliczne referencje mogą być zepsute ... Spróbuj zastąpić je domyślną gałęzią w następujący sposób: Na przykład moja domyślna gałąź to master

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

To powinno to naprawić.

— Conal Trinitrotoluene Da Costa
źródło

0

Jeśli używasz drzew roboczych git, upewnij się, że wykonujesz plik

git worktree prune

przed uruchomieniem

git gc

Doszło do zepsucia drzewa roboczego i po usunięciu uszkodzonego drzewa roboczego wydawało się, że to wystarczy. git prunesamo w sobie nie wydawało się działać.

— JeffP
źródło

0

Przyczyną tego dla mnie była praca w skompresowanym folderze w systemie Windows. Gdy folder został zdekompresowany, spowodował uszkodzenie plików paczek, powodując kaskadowe inne dziwne problemy, takie jak niemożność przycięcia nieistniejących gałęzi.

Jedynym rozwiązaniem było wyczyszczenie katalogu roboczego i ponowne sklonowanie pilota (ów) repozytorium. Na szczęście nadal mogłem naciskać i pobierać aktualizacje, aby nic nie zginęło. Teraz wszystko jest dobrze.

— Will Strohl
źródło