Pytanie Repozytorium Git złamane po śmierci komputera


Mój komputer zginął, a teraz jeden z moich repozytoriów git jest zepsuty. Kiedy próbuję wymyślić kasę, mówi mi:

warning: ignoring broken ref refs/heads/master.
error: Your local changes to the following files would be overwritten by checkout:
        com.vainolo.jdraw2d.releng.p2/pom.xml
Please, commit your changes or stash them before you can switch branches.
Aborting

Kiedy wykonuję git stash Dostaję:

fatal: bad revision 'HEAD'
fatal: bad revision 'HEAD'
fatal: Needed a single revision
You do not have the initial commit yet

Więc co mogę zrobić?

Aktualizacja Wyjście z git reflog:

fatal: bad default revision 'HEAD'

Niezbyt obiecujące ... Wyjście git fsck:

error: Invalid HEAD
Checking object directories: 100% (256/256), done.
error: unable to unpack 59551f96b4e87a1c14293c19eb548ce6fa1f196f header
error: inflateEnd: stream consistency error (no message)
fatal: loose object 59551f96b4e87a1c14293c19eb548ce6fa1f196f (stored in .git/objects/59/551f96b4e87a1c14293c19eb548ce6fa1f196f) is corrupt

76
2018-03-09 23:20


pochodzenie


Czy możesz to sprawdzić? .git/refs/heads/master istnieje i jeśli jego zawartość jest poprawnym hashiem zatwierdzenia twojego repozytorium (możesz to sprawdzić np. używając git show <hash>)? - poke
Wiem, że to oczywiste, ale wciąż zadając pytanie - czy masz jakieś zdalne repozytorium tego samego repozytorium git? - Tuxdude
@Dotknij zawartość .git/refs/heads/master/ jest kilka ^@ - vainolo
@Tuxdude yep, ale nie zaktualizowano moich ostatnich zmian - vainolo
Co robi git reflog powiedzieć ci? Czy próbowałeś już biegać? git fsck? - kynan


Odpowiedzi:


Udało mi się odzyskać dzięki:

rm .git/refs/remotes/origin/HEAD
git fetch --all

156
2018-03-10 04:47



W moim przypadku stało się tak, ponieważ usunąłem niektóre lokalne i zdalne gałęzie (w jakiś sposób plik .git / refs / remote / origin / HEAD pozostał w niespójnym stanie). Zmiana zawartości wyżej wymienionego pliku w celu wskazania istniejącego lokalnego odgałęzienia (np. Ref: refs / remote / origin / master) rozwiązała ten problem. Mimo to powyższe podejście może być lepsze, ponieważ HEAD może wskazywać na zatwierdzenie nie w bieżącym oddziale. - crissdev
W przypadku wystąpienia problemu z konkretnym modułem git, pierwsze polecenie nieznacznie zmienia się na rm <root repository path>/.git/modules/<path to the submodule>/refs/remotes/origin/HEAD - Gobe


Zacznij od wykonania kroków sugerowanych w Odzyskiwanie uszkodzonego repozytorium git:

  • Sprawdź pogodę .git/refs nadal zawiera wszystko, co jest przydatne
  • czek git reflog i zawodzi, że zawartość .git/logs/refs/heads/master lub jakakolwiek gałąź, w której byłeś ostatni
  • biegać git fsck, potencjalnie z --unreachable lub --lost-found

To na szczęście pozwoli ci dowiedzieć się, co master ref powinien być taki, abyś mógł go przywrócić (np .git/refs/heads/master).

Jeśli jakiś obiekt zawarty w tym zatwierdzeniu jest rzeczywiście uszkodzony, nie można go przywrócić HEAD Zatwierdź niestety. Zakładając, że twoje działające drzewo i / lub indeks są nienaruszone, możesz spróbować git reset --soft (lub nie, że git reset) do poprzedniego zatwierdzenia, a następnie ponownie wykonaj commit. Unikaj wszelkich operacji, które zmieniają twoje drzewo robocze s.a. git checkout -f lub git reset --hard.


18
2018-03-09 23:39



spojrzałem na .git/logs/refs/heads/mybranch. Pokazuje jakąś historię zobowiązań w tej branży. Przeszukując to, wybrałem SHA i próbowałem je wyświetlić git show. (Każde zatwierdzenie ma dwa SHA, wybrałem drugi, tuż przed nazwiskiem autora.) Ostatni był uszkodzony, ale poprzedni mógł być git shown, a następnie mogłem go popchnąć git push origin abcdef:mybranch. - Ed Avis


Miałem podobny problem po niebieskim ekranie śmierci w Windows 8.1

Miałem plik w tej lokalizacji ...

C:\www\<project>\.git\refs\remotes\origin\<problem-branch>

I był pusty, podczas gdy inne pliki gałęzi w tym folderze mają długie łańcuchy w nich.

NB Nie miałem żadnych zmian / zobowiązań

  • Poparłem kopię <problem-branch> plik
  • Usunięto plik
  • git fetch --all ponownie zdobyć oddział

Następnie automatyczne uzupełnianie karty zaczęło działać ponownie


9
2017-11-04 10:18





Jeśli nie ma wielu zmodyfikowanych plików, myślę, że wygodnym sposobem rozwiązania tego problemu jest:

  1. wykonaj kopię zapasową plików zmodyfikowanych w repozytorium
  2. usuń istniejące repozytorium
  3. ponownie sklonuj go z serwera
  4. wklej pliki z kroku 1 do repozytorium, i git commit -a 

5
2018-03-10 10:55



tak, nikt nie mógł pomyśleć o ponownym klonowaniu. świetna sugestia - Selman Genç


udało mi się to rozwiązać poprzez usunięcie pliku głównego w katalogu git \ refs \ heads


2
2018-03-18 15:02





Wiem, że to zbyt późna odpowiedź, ale dostałem ten błąd, ponieważ nie miałem origin/head. Możesz to znaleźć, uruchamiając git branch -r. Jeśli nie widzisz swojego origin/head wskazując na zdalne źródło, możesz to ustawić, uruchamiając git remote set-head origin {{your branch name}}.

Teraz biegnij git branch -r i powinieneś zobaczyć coś takiego: origin/HEAD -> origin/develop

Mam nadzieję, że pomoże to każdemu, kto korzysta z tego problemu.


1
2018-06-13 18:39





Po obliczonym zawieszeniu i awarii mój oddział git został uszkodzony z komunikatem: git fatal: your current branch appears to be broken. Nie mogłem nic zrobić.

Po zrobieniu git fsck wspomniał, że oddział miał error: Invalid HEAD. refs/heads/<branch> miał invalid sha1 pointer.

Po przejściu do opcji tutaj, otworzyłem .git/refs/heads/<branch> w edytorze notatnika ++, a każda z postaci sha1 była NUL.

Na szczęście wystarczy tylko zresetować gałąź do stanu zdalnego, i to było na repo bitbucket. Złapałem sha1 z końcówki zdalnego repo i skopiowałem do .git/refs/heads/<branch> zachował to, a potem zrobił git reset --hard HEADi wszystko wróciło do normy.


1
2017-10-04 14:16





Miałem ten sam problem, ale bez powodzenia, nie mogłem zrozumieć problemu. Wziąłem repo na bok, ponownie sklonowałem ten z serwera i próbowałem połączyć się z nimi. Oczywiście pokazywał on wiele plików niezwiązanych z moją gałęzią, ale pomagał wyodrębnić wymagane pliki.


0
2017-11-12 11:32





Sprawdź, czy w MSWindows utworzono pliki desktop.ini, które są zgodne z gitem? to robi dla mnie. Po usunięciu ich wszystkich w podfolderach katalogu .git, to działa.


0
2018-06-05 14:02





Miałem ten sam problem, gdy Android Studio nagle się zakończył (z powodu utraty zasilania komputera).

Rozwiązałem go, kopiując zawartość mojego C:\Users\myusername\AndroidStudioProjects\MyBrokenApp\.git\refs\heads\master plik do mojego C:\Users\myusername\AndroidStudioProjects\MyBrokenApp\.git\refs\remotes\origin\master plik.

(Wcześniej włączyłem opcję Force Push w Android Studio, ale uważam, że nie był to konieczny krok.)

Uwaga:

Znalazłem to rozwiązanie, porównując zawartość plików w moim C:\Users\myusername\AndroidStudioProjects\MyBrokenApp\.git\ katalog (w tym podkatalogi) do odpowiednich plików plików w innych zdrowy projekt - np. C:\Users\myusername\AndroidStudioProjects\MyHealthyApp\.git\.

Możesz mieć inny plik, który jest uszkodzony, ale porównując go z innym zdrowym projektem, powinieneś być w stanie szybko wykryć, co jest nie tak.

Jeśli nie masz innego zdrowego projektu, który ma skonfigurowany git, może być warte utworzenie prostego w taki sam sposób, w jaki stworzyłeś zepsuty projekt, aby można było zbadać, porównać i naprawić itp.

PS - Mój komunikat o błędzie (edytowany): warning: ignoring broken refs/remotes/origin/master.fatal bad revision 'refs/remotes/origin/master..refs/heads/master' during executing git -c core.quotepath=false log refs/remotes/origin/master..refs/heads/master --pretty=format --encoding=UTF-8 -M --name-status -c --


0
2017-07-07 12:16





Byłem idiotą na tyle, aby zapomnieć o pchaniu, a mój komputer rozbił się podczas wykonywania zatwierdzenia. Mogę odzyskać wszystko oprócz ostatniego zatwierdzenia przez otwarcie .git / logs / refs / heads /

Ten plik zawiera wszystkie zatwierdzenia (z ich SHA) do oddziału, co zrobiłem do odzyskania:

  • Twórz kopie najnowszych zmian w folderze tymczasowym
  • przenieść się na "czysty łupek"
    • git checkout master
    • git reset --hard
  • kasuj drugie do ostatniego zatwierdzenia w dzienniku
  • stwórz gałąź z tej odłączonej głowy
  • PCHAĆ
  • Przywróć ostatnie zmiany
  • Zatwierdź ponownie

Więc nawet kiedy popełnisz głupi błąd, nie jesteś natychmiast odbierany przez cały dzień pracy z git :)


0
2017-08-03 08:59