Jak radzić sobie z tym błędem git

Question

ja dostaję ten błąd w moim repozytorium git:

22:09:15 $ git status 
# On branch master 
error: Could not read 8124cc15c63be92d534e4cdfa33c38d54deee122 
error: unable to read tree object HEAD 
nothing to commit (working directory clean) 

Wyszukiwarka Google dla error: unable to read tree object HEAD nie powoduje większej pomocy, ten błąd wydaje się być bardzo rzadkie. Nie jestem pewien, jak sobie z tym poradzić. Czy może to być awaria dysku twardego?

Edit: Wyjście git fsck jest następujący:

broken link from commit 607328dc80e4901a55b95c683d4fbf43e6df28bf 
       to tree 8124cc15c63be92d534e4cdfa33c38d54deee122 
missing tree 8124cc15c63be92d534e4cdfa33c38d54deee122 
dangling tree 56b5d4a5e429d251582ec927bca7ef1225510c41 
dangling tree 0259d2d38b18b6136bb6070fb41faf3624453cc6 

Answer 1

W komunikacie "niedziałający link", można śledzić GitFaq recommendations:

• kopię zapasową wszystkich stan, aby wszystko, co robisz, można było ponownie naprawić, jeśli coś więcej zepsujesz!
• eksplodować żadnych uszkodzonych opakowań-plików
  • Patrz "man git-unpack-objects", aw szczególności flaga "-r".
    Należy również pamiętać, że tylko rozpakowuje on obiekty, które nie są jeszcze dostępne, dlatego najpierw należy przenieść plik z dala od normalnej lokalizacji (w przeciwnym razie git-unpack-objects znajdzie wszystkie obiekty znajdujące się w pliku pakietu w pakiecie -file się, i niczego nie rozpakować w ogóle)
• wymienić wszelkie uszkodzone i/lub brakujących przedmiotów
  • to jest wyzwaniem.
    Czasami (miejmy nadzieję, że często!) Można znaleźć brakujące obiekty w innych kopiach repozytoriów.
    W innych przypadkach może zajść potrzeba wyszukiwania danych w inny sposób (na przykład, może wyewidencjonowana kopia zawiera zawartość pliku, która po haszowaniu będzie brakującym obiektem?).
• upewnić, że wszystko jest zadowolony z "git fsck --full"
• zapakować wszystko, aby wrócić do sprawnego stanu ponownie

---

Uwagi:

• brakujące przedmioty mogą również być related to alternate (po share objects between repositories) wi th git alternates (nawet jeśli to can be risky).
• Wtyczka do zaćmienia JGit/Egit jest również znana z have a few issues.
  (Aktualizacja luty 2012: those plugins Przebyliśmy długą drogę i są teraz dość stabilne)

Aktualizacja lipca 2016 (7 lat Laters), z Git 2.10 wkrótce zostanie zwolniony, masz teraz:

git fsck --name-objects 

Pomaga nazywania pochodzenie tych niedziałających linków

patrz „How to fix git error broken link from tree to tree?” więcej.

Answer 2

Miałem ten sam problem. Po wielu ciągnięciach włosów odkryłem, że było to spowodowane przez zmienione pozwolenie na pliki git repozytorium. Rozwiązałem go w następujący sposób:

$ cd .git 
$ chmod 755 * 

Zrobione!

Answer 3

W tej chwili miałem podobny problem. Zepsuło się, gdy mój laptop wyłączył się podczas git pull. Mam zdalne repozytorium kopii zapasowych. Najpierw miałem kilka plików obiektów w .git/objects/??/*, które miały zerowy rozmiar. Po cp -a kopii zapasowej repozytorium, zrobiłem to:

• usunąć zerowej długości obiektów
• klon zdalnego repozytorium do ../fresh/ repozytorium

• w podziale repozytorium, zrobiłem

  cat ../fresh/.git/objects/pack/pack-*.pack | git unpack-objects

To wypełniło brakujące obiekty w baza danych obiektów. Repozytorium wydaje się być teraz ponownie.

Answer 4

Jeśli nie masz uncommited zmiany najprostszym rozwiązaniem jest usunięcie lokalnego oddziału: git branch -D [nazwa oddziału]

a potem kasa znowu pilot Branża: git checkout -b [oddział nazwa] origin/[nazwa oddziału]

Answer 5

Mam podobny błąd w moim repozytorium Git z Homebrew instalacji. Zamiast przywracania wszystkich brakujących obiektów jeden po drugim, łatwiej było po prostu usunąć katalog .git i utworzyć go ponownie, ponownie klonując z Homebrew’s public repository. Oto moje kroki:

• Sprawdź, jakie informacje posiadasz w swoim repozytorium Git, których nie dostaniesz po prostu przez ponowne klonowanie. Dla mnie były to prywatne oddziały, skrytki i piloty.
  • Konwertuj pliki do prawdziwego commitowania, tworząc nowy oddział, stosując skrytkę i zatwierdzając coś takiego jak "[WIP]" w nazwie, aby pokazać, że jest to skrytka.
  • Zapisz gałęzie, które nie znajdują się w publicznym pilocie, przesyłając je do własnego pilota. Może to być widelec repozytorium na GitHub lub po prostu nowe repozytorium Git w innej lokalizacji na twoim komputerze.
  • Jeśli masz więcej niż jeden pilot, zapisz dane wyjściowe z git remote -v, które zawiera nazwy i adresy URL twoich pilotów, aby móc ręcznie dodać je później.
• Usuń katalog repojawii o numerze .git (lub zmień jego nazwę na .git-broken i usuń go później). W wierszu polecenia jest to rm -rf .git.
• Ponownie sklonuj katalog zdalny za pomocą git clone https://github.com/Homebrew/homebrew.git lub dowolnego identyfikatora URI.
• Spowoduje to utworzenie nowego podfolderu homebrew nazwanego po repozytorium. Chcesz od tego tylko katalog .git; Twoje lokalne pliki są już w porządku. Więc mv homebrew/.git .git, a następnie usuń folder homebrew.
• Twoje repozytorium Git nie powinno zawierać błędów, ponieważ odtworzono go od początku. Teraz przywróć wszystkie informacje zapisane w pierwszym kroku.
  • Jeśli masz dodatkowe piloty, dodaj je ponownie pod numerem git remote add <name> <url>.
  • Jeśli utworzono kopie zapasowe wszelkich gałęzi (lub magazynów przekształconych w gałęzie) do zdalnego repozytorium, należy je pobrać z tego repozytorium do lokalnego repozytorium.
  • Jeśli chcesz, możesz przekonwertować gałęzie magazynów z powrotem na skrytki, przewijając zatwierdzenie "[WIP]" z git reset HEAD^ i ponownie zapisując katalog roboczy w magazynie za pomocą git stash save <custom-message>.

Jeśli prowadzisz git fsck, powinieneś zobaczyć błędów:

$ git fsck 
Checking object directories: 100% (256/256), done. 
Checking objects: 100% (197135/197135), done. 
Checking connectivity: 197162, done. 
$ 

I git stash list, git branch i git remote -v powinny wykazywać taką samą moc, jak wcześniej.

Answer 6

Naprawiłem błąd, wprowadzając zmiany w tym samym katalogu/folderze projektu, a następnie próbowałem zatwierdzić nową zmianę, co się stało, otrzymałem komunikat o błędzie "nieprawidłowy obiekt 100644 e38e910ceb18b09f436f353c3a131bfe2caba130 dla" Book/alise_mathe/app/src/main/res/menu/drawermenu.xml ' to msg rozwiązało problem, właśnie refaktoryzowałem plik drawermenu.xml, zmieniając nazwę pliku na "drawer_menu.xml". dodał zmiany zatwierdzone i to wszystko. (Android-studio)

Mam nadzieję, że to pomoże trochę jak

Answer 7

naprawiłem ten błąd usuwając „repo” Folder CAPISTRANO z mojego katalogu serwera zdalnego. Przeszedłem przez wiele innych sugerowanych problemów i zdecydowałem, że problem nie leży w moim lokalnym projekcie. Problem pojawił się, gdy Capistrano wykonywał ciągnięcie od repo do pilota. Dla mnie było to prawdopodobnie spowodowane zatrzymanym wdrożeniem, które pozostawiało uszkodzone odwołania do obiektów/obiektów. Mój gospodarz właśnie przeprowadził migrację serwera, być może coś uległo uszkodzeniu podczas tego procesu.