Ilekroć wyciągam z pilota, pojawia się następujący błąd dotyczący kompresji. Po uruchomieniu kompresji ręcznej otrzymuję to samo:

$ git gc
error: Could not read 3813783126d41a3200b35b6681357c213352ab31
fatal: bad tree object 3813783126d41a3200b35b6681357c213352ab31
error: failed to run repack

Czy ktoś wie, co z tym zrobić?

Z pliku cat otrzymuję to:

$ git cat-file -t 3813783126d41a3200b35b6681357c213352ab31
error: unable to find 3813783126d41a3200b35b6681357c213352ab31
fatal: git cat-file 3813783126d41a3200b35b6681357c213352ab31: bad file

I z git fsck otrzymuję to (nie wiem, czy to jest rzeczywiście powiązane):

$ git fsck
error: inflate: data stream error (invalid distance too far back)
error: corrupt loose object '45ba4ceb93bc812ef20a6630bb27e9e0b33a012a'
fatal: loose object 45ba4ceb93bc812ef20a6630bb27e9e0b33a012a (stored in .git/objects/45/ba4ceb93bc812ef20a6630bb27e9e0b33a012a) is corrupted

Czy ktoś może mi pomóc to rozszyfrować?

Wygląda na to, że masz uszkodzony obiekt drzewa. Musisz zdobyć ten obiekt od kogoś innego. Mam nadzieję, że będą miały niezniszczoną wersję.

Możesz go zrekonstruować, jeśli nie możesz znaleźć prawidłowej wersji od innej osoby, zgadując, jakie pliki powinny tam być. Możesz sprawdzić, czy daty i godziny obiektów odpowiadają temu. Mogą to być powiązane obiekty BLOB. Z tych obiektów można wywnioskować strukturę obiektu drzewa.

Spójrz na Git Screencasts Scott Chacon dotyczące wewnętrznych elementów gita. To pokaże ci, jak git działa pod maską i jak wykonać tę pracę detektywistyczną, jeśli naprawdę utkniesz i nie możesz dostać tego obiektu od kogoś innego.

Miałem ten sam problem (nie wiem dlaczego).

Ta poprawka wymaga dostępu do nieuszkodzonej zdalnej kopii repozytorium i utrzymuje lokalną kopię roboczą w stanie nienaruszonym.

Ma jednak pewne wady:

• Utracisz zapis wszelkich zatwierdzeń, które nie zostały wypchnięte, i będziesz musiał je ponownie wprowadzić.
• Stracisz wszystkie skrytki.

Poprawka

Wykonaj te polecenia z katalogu nadrzędnego nad repozytorium (zamień „foo” na nazwę folderu projektu):

1. Utwórz kopię zapasową uszkodzonego katalogu:
   cp -R foo foo-backup
2. Utwórz nowy klon zdalnego repozytorium w nowym katalogu:
   git clone [email protected]:foo foo-newclone
3. Usuń uszkodzony podkatalog .git:
   rm -rf foo/.git
4. Przenieś nowo sklonowany podkatalog .git do foo:
   mv foo-newclone/.git foo
5. Usuń resztę tymczasowego nowego klonu:
   rm -rf foo-newclone

W systemie Windows musisz użyć:

• copy zamiast cp -R
• rmdir /S zamiast rm -rf
• move zamiast mv

Teraz foo ma swój oryginalny .gitpodkatalog, ale wszystkie lokalne zmiany nadal tam są. git status, commit, pull, push, Itd. Praca znowu tak, jak powinny.

Najlepszym rozwiązaniem jest prawdopodobnie ponowne klonowanie ze zdalnego repozytorium (np. Github lub innego). Niestety utracisz nieprzypisane zatwierdzenia i ukryte zmiany, jednak kopia robocza powinna pozostać nienaruszona.

Najpierw wykonaj kopię zapasową lokalnych plików. Następnie zrób to z katalogu głównego działającego drzewa:

rm -fr .git
git init
git remote add origin [your-git-remote-url]
git fetch
git reset --mixed origin/master
git branch --set-upstream-to=origin/master master  

Następnie w razie potrzeby zatwierdz wszystkie zmienione pliki.

Pracując na maszynie wirtualnej, w moim notebooku bateria się skończyła, wystąpił ten błąd;

error: plik obiektowy .git / objects / ce / theRef jest pusty błąd: plik obiektowy .git / objects / ce / theRef jest pusty fatal: luźny obiekt theRef (przechowywany w .git / objects / ce / theRef) jest uszkodzony

Udało mi się sprawić, że repo znów działa z tylko 2 poleceniami i bez utraty pracy (zmodyfikowane pliki / niezatwierdzone zmiany)

find .git/objects/ -size 0 -exec rm -f {} \;
git fetch origin

Potem prowadziłem git status , repo było w porządku i były moje zmiany (czekam na zatwierdzenie, zrób to teraz ...).

wersja git 1.9.1

Pamiętaj, aby wykonać kopię zapasową wszystkich zapamiętanych zmian, na wypadek, gdyby to rozwiązanie nie działało i potrzebne jest bardziej radykalne podejście.

Mój komputer zawiesił się podczas pisania wiadomości zatwierdzenia. Po ponownym uruchomieniu działające drzewo wyglądało tak, jak je zostawiłem i mogłem pomyślnie zatwierdzić zmiany.

Jednak kiedy próbowałem uciec git status, dostałem

error: object file .git/objects/xx/12345 is empty
fatal: loose object xx12345 (stored in .git/objects/xx/12345 is corrupt

W przeciwieństwie do większości innych odpowiedzi, nie próbowałem odzyskać żadnych danych . Potrzebowałem tylko Gita, żeby przestał narzekać na pusty plik obiektowy.

Przegląd

„Plik obiektowy” to haszowana reprezentacja rzeczywistego pliku, na którym ci zależy. Git uważa, że ​​powinna być w nim some/file.whateverzapisana zaszyfrowana wersja .git/object/xx/12345, a naprawienie błędu polegało głównie na ustaleniu, który plik „luźny obiekt” miał reprezentować.

Detale

Wydawało się, że możliwe są opcje

1. Usuń pusty plik
2. Ustaw plik w stanie akceptowanym przez Git

Podejście 1: Usuń plik obiektowy

Pierwszą rzeczą, jakiej próbowałem, było przeniesienie pliku obiektowego

mv .git/objects/xx/12345 ..

To nie zadziałało - git zaczął narzekać na zepsuty link. Przejdź do podejścia 2.

Podejście 2: Napraw plik

Linus Torvalds świetnie napisał, jak odzyskać plik obiektowy, który rozwiązał dla mnie problem. Kluczowe kroki zostały podsumowane tutaj.

$> # Find out which file the blob object refers to
$> git fsck
broken link from    tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
           to    blob xx12345
missing blob xx12345

$> git ls-tree 2d926
...
10064 blob xx12345  your_file.whatever

To powie ci, jaki plik ma być skrótem pustego obiektu. Teraz możesz to naprawić.

$> git hash-object -w path/to/your_file.whatever

Po zrobieniu tego sprawdziłem .git/objects/xx/12345, że nie jest już pusty, a git przestał narzekać.

Próbować

git stash

To zadziałało dla mnie. Ukrywa wszystko, czego nie popełniłeś i co pomijało problem.

Zbieranie śmieci stały mój problem:

git gc --aggressive --prune=now

Trwa trochę czasu, ale każdy luźny obiekt i / lub uszkodzony indeks został naprawiony.

po prostu git prunenaprawiłem ten problem

Właśnie tego doświadczyłem - moja maszyna uległa awarii podczas pisania do repozytorium Git i uległa uszkodzeniu. Naprawiłem to w następujący sposób.

Zacząłem od sprawdzenia, ile zatwierdzeń nie wypchnąłem do zdalnego repozytorium, a zatem:

gitk &

Jeśli nie korzystasz z tego narzędzia, jest ono bardzo przydatne - dostępne, o ile wiem, we wszystkich systemach operacyjnych. Oznaczało to, że mój pilot nie miał dwóch zatwierdzeń. Dlatego kliknąłem etykietę wskazującą ostatnie zdalne zatwierdzenie (zwykle tak będzie/remotes/origin/master ), aby uzyskać skrót (skrót ma 40 znaków, ale dla zwięzłości używam tutaj 10 - i tak zazwyczaj działa).

Oto on:

14c0fcc9b3

Następnie klikam następujące zatwierdzenie (tj. Pierwsze, którego nie ma pilot) i tam mam skrót:

04d44c3298

Następnie używam obu z nich, aby zrobić łatkę dla tego zatwierdzenia:

git diff 14c0fcc9b3 04d44c3298 > 1.patch

Następnie zrobiłem podobnie z innym brakującym zatwierdzeniem, tj. Użyłem skrótu wcześniejszego zatwierdzenia i skrótu samego zatwierdzenia:

git diff 04d44c3298 fc1d4b0df7 > 2.patch

Następnie przeniosłem się do nowego katalogu, sklonowałem repozytorium ze zdalnego:

git clone [email protected]:username/repo.git

Następnie przeniosłem pliki łatek do nowego folderu, zastosowałem je i zatwierdziłem ich dokładnymi komunikatami zatwierdzenia (można je wkleić z okna git loglub w gitkoknie):

patch -p1 < 1.patch
git commit

patch -p1 < 2.patch
git commit

To przywróciło mi rzeczy (i zauważ, że istnieje prawdopodobnie szybszy sposób na zrobienie tego dla dużej liczby zatwierdzeń). Chciałem jednak sprawdzić, czy drzewo w uszkodzonym repozytorium można naprawić, a odpowiedź brzmi: tak. Przy naprawionym repozytorium dostępnym jak wyżej, uruchom to polecenie w uszkodzonym folderze:

git fsck 

Otrzymasz coś takiego:

error: object file .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d is empty
error: unable to find ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d
error: sha1 mismatch ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d

Aby wykonać naprawę, zrobiłbym to w uszkodzonym folderze:

rm .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d
cp ../good-repo/.git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d

tzn. usuń uszkodzony plik i zastąp go dobrym. Być może będziesz musiał to zrobić kilka razy. Wreszcie będzie punkt, w którym będziesz mógł biegaćfsck bez błędów. Prawdopodobnie będziesz mieć w raporcie wiersze „zwisające zatwierdzenie” i „zwisające kropelki”, są one konsekwencją twoich zmian i poprawek w tym folderze i są OK. Śmieciarka usunie je w odpowiednim czasie.

Zatem (przynajmniej w moim przypadku) zepsute drzewo nie oznacza, że ​​niepoprawne zatwierdzenia zostały utracone.

Otrzymałem również uszkodzony błąd luźnego obiektu.

./objects/x/x

Udało mi się to naprawić, wchodząc do katalogu uszkodzonego obiektu. Widziałem, że użytkownicy przypisani do tego obiektu nie byli moim użytkownikiem git. Nie wiem, jak to się stało, ale uruchomiłem chown git:gitten plik, a potem znowu zadziałał.

Może to być potencjalna poprawka dla problemów niektórych ludzi, ale niekoniecznie dla wszystkich.

Ten błąd wystąpił po tym, jak moja maszyna (Windows) postanowiła zrestartować się. Na szczęście moje zdalne repozytorium było aktualne, więc właśnie wykonałem świeżego klon git.

Runnning git stash; git stash popnaprawił mój problem

Wykonałem wiele innych kroków tutaj; Szczególnie pomocny był opis Linusa, w jaki sposób spojrzeć na drzewo / obiekty git i znaleźć to, czego brakuje. git-git odzyskuje uszkodzony obiekt blob

Ale ostatecznie dla mnie miałem luźne / uszkodzone obiekty drzewa spowodowane częściową awarią dysku, a obiekty drzewa nie są tak łatwo odzyskiwać / nie są objęte tym dokumentem.

Ostatecznie usunąłem konflikt objects/<ha>/<hash>z drogi i użyłem go git unpack-objectsz plikiem paczki z dość aktualnego klonu. Był w stanie przywrócić brakujące obiekty drzewne.

Wciąż pozostawiło mi wiele zwisających kropelek, które mogą być efektem ubocznym rozpakowywania wcześniej zarchiwizowanych rzeczy i poruszone w innych pytaniach tutaj

W odpowiedzi na @ user1055643 brakuje ostatniego kroku:

$ rm -fr .git
$ git init
$ git remote add origin your-git-remote-url
$ git fetch
$ git reset --hard origin/master
$ git branch --set-upstream-to=origin/master master  

Właśnie mieliśmy tu sprawę. Zdarzyło się, że problem polegał na tym, że właścicielem uszkodzonego pliku był root zamiast naszego zwykłego użytkownika. Było to spowodowane zatwierdzeniem dokonanym na serwerze po tym, jak ktoś zrobił „sudo su -”.

Najpierw zidentyfikuj uszkodzony plik za pomocą:

$> git fsck --full

Powinieneś otrzymać odpowiedź taką jak ta:

fatal: loose object 11b25a9d10b4144711bf616590e171a76a35c1f9 (stored in .git/objects/11/b25a9d10b4144711bf616590e171a76a35c1f9) is corrupt

Przejdź do folderu, w którym znajduje się uszkodzony plik i wykonaj:

$> ls -la

Sprawdź własność uszkodzonego pliku. Jeśli jest inaczej, po prostu wróć do katalogu głównego repozytorium i wykonaj:

$> sudo chown -R YOURCORRECTUSER:www-data .git/

Mam nadzieję, że to pomoże!

Dla mnie stało się to z powodu awarii zasilania podczas robienia git push.

Wiadomości wyglądały tak:

$ git status
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
fatal: loose object c238824eb3fb602edc2c49fccb535f9e53951c74 (stored in .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74) is corrupt

Próbowałem takich rzeczy, git fsckale to nie pomogło. Ponieważ awaria nastąpiła podczas a git push, oczywiście stało się to podczas przepisywania po stronie klienta, co dzieje się po aktualizacji serwera. Rozejrzałem się dookoła i doszedłem do wniosku, że c2388w moim przypadku był to obiekt zatwierdzenia, ponieważ do niego odwoływały się wpisy w .git/refs. Wiedziałem więc, że będę mógł je znaleźć, c2388kiedy spojrzę na historię (przez interfejs sieciowy lub drugi klon).

Na drugim klonie zrobiłem a, git log -n 2 c2388aby zidentyfikować poprzednika c2388. Następnie ręcznie zmodyfikowałem .git/refs/heads/masteri zamiast tego byłem .git/refs/remotes/origin/masterpoprzednikiem . Wtedy mógłbym zrobić . Powiodło się kilka razy do konfliktów na pustych obiektów. Usunąłem każdy z tych pustych obiektów, dopóki się nie udało. To wyleczyło repozytorium.c2388c2388git fetchgit fetchgit fetch

Rozwiązałem w ten sposób: postanowiłem po prostu skopiować nieuszkodzony plik obiektowy z klonu kopii zapasowej do mojego oryginalnego repozytorium. To działało równie dobrze. (Nawiasem mówiąc: Jeśli nie możesz znaleźć obiektu w .git / objects / według jego nazwy, prawdopodobnie został on [spakowany] [paczka], aby zaoszczędzić miejsce.)

Miałem ten sam problem w moim nagim zdalnym repozytorium git. Po wielu problemach zorientowałem się, że jeden z moich współpracowników dokonał zatwierdzenia, w którym niektóre pliki w .git / objects miały uprawnienia 440 (r - r -----) zamiast 444 (r - r - r -). Po poproszeniu współpracownika o zmianę uprawnień za pomocą „obiektów chmod 444 -R” wewnątrz repozytorium git, problem został naprawiony.

Właśnie miałem taki problem. Mój szczególny problem został spowodowany przez awarię systemu, która spowodowała uszkodzenie ostatniego zatwierdzenia (a więc i gałęzi master). Nie naciskałem i chciałem ponownie dokonać tego zatwierdzenia. W moim szczególnym przypadku mogłem sobie z tym poradzić w następujący sposób:

1. Wykonaj kopię zapasową .git/:rsync -a .git/ git-bak/
2. Sprawdź .git/logs/HEADi znajdź ostatni wiersz z prawidłowym identyfikatorem zatwierdzenia. Dla mnie było to drugie ostatnie zatwierdzenie. To było dobre, ponieważ nadal miałem wersje katalogu roboczego pliku, a więc każdą wersję, której chciałem.
3. Utwórz gałąź przy tym zatwierdzeniu: git branch temp <commit-id>
4. ponownie wykonaj uszkodzony commit z plikami w katalogu roboczym.
5. git reset master temp aby przenieść gałąź master do nowego zatwierdzenia dokonanego w kroku 2.
6. git checkout masteri sprawdź, czy wygląda poprawnie git log.
7. git branch -d temp.
8. git fsck --full, i teraz powinno być bezpiecznie usuwać uszkodzone obiekty znalezione przez fsck.
9. Jeśli wszystko wygląda dobrze, spróbuj pchać. Jeśli to zadziała,

To działało dla mnie. Podejrzewam, że jest to dość powszechny scenariusz, ponieważ najprawdopodobniej najnowszy zatwierdzenie jest uszkodzony, ale jeśli stracisz jeszcze jedną pozycję wstecz, prawdopodobnie nadal możesz użyć takiej metody, ostrożnie ją wykorzystując git cherrypicki przeprogramować w .git/logs/HEAD.

Kiedy miałem ten problem, utworzyłem kopię zapasową moich ostatnich zmian (ponieważ wiedziałem, co zmieniłem), a następnie usunąłem ten plik, na który narzekałem w .git / location. Potem zrobiłem dupek. Uważaj jednak, może to nie działać.

Spotkałem to, gdy mój system się zawiesił. Zrobiłem to:

(Pamiętaj, że twoje uszkodzone zatwierdzenia zostały utracone, ale zmiany zostały zachowane. Być może będziesz musiał odtworzyć te zatwierdzenia na końcu tej procedury)

• Utwórz kopię zapasową kodu.
• Przejdź do katalogu roboczego i usuń .git folder.
• Teraz sklonuj pilota w innej lokalizacji i skopiuj .git folder.
• Wklej go do katalogu roboczego.
• Zaangażuj się, jak chcesz.

Wystarczy usunąć folder .git i dodać go ponownie. To proste rozwiązanie zadziałało dla mnie.