Jak naprawić błąd GIT: plik obiektowy jest pusty?

Gdy próbuję zatwierdzić zmiany, pojawia się ten błąd:

error: object file .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0 is empty
fatal: loose object 3165329bb680e30595f242b7c4d8406ca63eeab0 (stored in .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0) is corrupt

Masz pomysł, jak rozwiązać ten błąd?

EDYTOWAĆ

Próbowałem git fsckMam:

error: object file .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71 is empty
fatal: loose object 03dfd60a4809a3ba7023cbf098eb322d08630b71 (stored in .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71) is corrupt

Miałem podobny problem. Mój laptop zabrakło baterii podczas operacji git. Gwizd.

Nie miałem żadnych kopii zapasowych. (Uwaga: Ubuntu One nie jest rozwiązaniem do tworzenia kopii zapasowych dla git; pomocnie zastąpi twoje rozsądne repozytorium uszkodzonym).

Jeśli jest to zły sposób na naprawienie tego problemu, zostaw komentarz. Jednak zadziałało to dla mnie ... przynajmniej tymczasowo.

Krok 1: Utwórz kopię zapasową .git (w rzeczywistości robię to pomiędzy każdym krokiem, który coś zmienia, ale z nową nazwą kopiowania na, np. .Git-old-1, .git-old-2 itp.) :

cp -a .git .git-old

Krok 2: Uruchom git fsck --full

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
error: object file .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e is empty
fatal: loose object 8b61d0135d3195966b443f6c73fb68466264c68e (stored in .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e) is corrupt

Krok 3: Usuń pusty plik. Zrozumiałem, co do cholery; i tak jest puste.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e 
rm: remove write-protected regular empty file `.git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e'? y

Krok 3: Uruchom git fsckponownie. Kontynuuj usuwanie pustych plików. Możesz także przejść cddo .gitkatalogu i uruchomić, find . -type f -empty -delete -printaby usunąć wszystkie puste pliki. W końcu git zaczął mi mówić, że w rzeczywistości coś robi z katalogami obiektów:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: object file .git/objects/e0/cbccee33aea970f4887194047141f79a363636 is empty
fatal: loose object e0cbccee33aea970f4887194047141f79a363636 (stored in .git/objects/e0/cbccee33aea970f4887194047141f79a363636) is corrupt

Krok 4: Po usunięciu wszystkich pustych plików w końcu zacząłem git fsckfaktycznie działać:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: HEAD: invalid sha1 pointer af9fc0c5939eee40f6be2ed66381d74ec2be895f
error: refs/heads/master does not point to a valid object!
error: refs/heads/master.u1conflict does not point to a valid object!
error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
missing blob 8b61d0135d3195966b443f6c73fb68466264c68e
missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a
missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd
missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229

Krok 5: Spróbuj git reflog. Niepowodzenie, ponieważ moja GŁOWA jest zepsuta.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git reflog
fatal: bad object HEAD

Krok 6: Google. Znajdź to . Ręcznie pobierz dwie ostatnie linie dziennika:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ tail -n 2 .git/logs/refs/heads/master
f2d4c4868ec7719317a8fce9dc18c4f2e00ede04 9f0abf890b113a287e10d56b66dbab66adc1662d Nathan VanHoudnos <nathanvan@gmail.com> 1347306977 -0400  commit: up to p. 24, including correcting spelling of my name
9f0abf890b113a287e10d56b66dbab66adc1662d af9fc0c5939eee40f6be2ed66381d74ec2be895f Nathan VanHoudnos <nathanvan@gmail.com> 1347358589 -0400  commit: fixed up to page 28

Krok 7: Zauważ, że z kroku 6 dowiedzieliśmy się, że HEAD wskazuje obecnie na ostatni zatwierdzenie. Spróbujmy więc spojrzeć na zatwierdzenie nadrzędne:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git show 9f0abf890b113a287e10d56b66dbab66adc1662d
commit 9f0abf890b113a287e10d56b66dbab66adc1662d
Author: Nathan VanHoudnos <nathanvan@XXXXXX>
Date:   Mon Sep 10 15:56:17 2012 -0400

    up to p. 24, including correcting spelling of my name

diff --git a/tex/MCMC-in-IRT.tex b/tex/MCMC-in-IRT.tex
index 86e67a1..b860686 100644
--- a/tex/MCMC-in-IRT.tex
+++ b/tex/MCMC-in-IRT.tex

Zadziałało!

Krok 8: Więc teraz musimy wskazać HEAD na 9f0abf890b113a287e10d56b66dbab66adc1662d.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git update-ref HEAD 9f0abf890b113a287e10d56b66dbab66adc1662d

Co nie narzekało.

Krok 9: Zobacz, co mówi fsck:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: refs/heads/master.u1conflict does not point to a valid object!
error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
missing blob 8b61d0135d3195966b443f6c73fb68466264c68e
missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a
missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd
missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229

Krok 10: Nieprawidłowy wskaźnik sha1 w drzewie pamięci podręcznej wyglądał tak, jakby pochodził z (obecnie nieaktualnego) pliku indeksu ( źródła ). Więc go zabiłem i zresetowałem repo.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ rm .git/index
nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git reset
Unstaged changes after reset:
M   tex/MCMC-in-IRT.tex
M   tex/recipe-example/build-example-plots.R
M   tex/recipe-example/build-failure-plots.R

Krok 11: Ponownie patrząc na fsck ...

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: refs/heads/master.u1conflict does not point to a valid object!
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a

W zwisające plamy nie są błędy . Nie interesuje mnie konflikt master.u1, a teraz, gdy działa, nie chcę go więcej dotykać!

Krok 12: Nadrobienie zaległości w lokalnych edycjach:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   tex/MCMC-in-IRT.tex
#   modified:   tex/recipe-example/build-example-plots.R
#   modified:   tex/recipe-example/build-failure-plots.R
#
< ... snip ... >
no changes added to commit (use "git add" and/or "git commit -a")


nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git commit -a -m "recovering from the git fiasco"
[master 7922876] recovering from the git fiasco
 3 files changed, 12 insertions(+), 94 deletions(-)

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git add tex/sept2012_code/example-code-testing.R
nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git commit -a -m "adding in the example code"
[master 385c023] adding in the example code
 1 file changed, 331 insertions(+)
 create mode 100644 tex/sept2012_code/example-code-testing.R

Mam więc nadzieję, że może to być przydatne dla ludzi w przyszłości. Cieszę się, że zadziałało.

Pliki obiektów git uległy uszkodzeniu (jak wskazano również w innych odpowiedziach). Może się to zdarzyć podczas awarii komputera itp.

Miałem to samo. Po przeczytaniu innych najważniejszych odpowiedzi tutaj znalazłem najszybszy sposób na naprawienie uszkodzonego repozytorium git za pomocą następujących poleceń (wykonaj w katalogu roboczym git, który zawiera .gitfolder):

(Najpierw wykonaj kopię zapasową folderu repozytorium git!)

find .git/objects/ -type f -empty | xargs rm
git fetch -p
git fsck --full

Spowoduje to najpierw usunięcie wszystkich pustych plików obiektowych, które powodują uszkodzenie repozytorium jako całości, a następnie pobranie brakujących obiektów (a także najnowszych zmian) ze zdalnego repozytorium, a następnie sprawdzenie pełnego magazynu obiektów . Które w tym momencie powinno odnieść sukces bez żadnych błędów (mogą być jednak pewne ostrzeżenia!)

PS. Ta odpowiedź sugeruje, że masz gdzieś zdalną kopię swojego repozytorium git (np. Na GitHub), a uszkodzone repozytorium to lokalne repozytorium, które jest powiązane ze zdalnym repozytorium, które jest nadal w takcie. Jeśli tak nie jest, nie próbuj tego naprawiać w sposób zalecany przeze mnie.

Ten błąd zdarza mi się, gdy wypycham mój zatwierdzenie i komputer zawiesza się. Tak to naprawiłem.

Kroki do naprawienia

git status

pokaż pusty / uszkodzony plik obiektowy

rm .git/objects/08/3834cb34d155e67a8930604d57d3d302d7ec12

usunąć to

git status

Dostałem fatal: bad object HEADwiadomość

rm .git/index

Usuwam indexdla resetu

git reset

fatal: Nie można przeanalizować obiektu „HEAD”.

git status
git pull

żeby sprawdzić co się dzieje

tail -n 2 .git/logs/refs/heads/MY-CURRENT-BRANCH

wypisuje ostatnie 2 linie tail -n 2gałęzi logów, aby pokazać moje ostatnie 2commit hash

git update-ref HEAD 7221fa02cb627470db163826da4265609aba47b2

Wybieram ostatni commit hash

git status

pokazuje wszystkie moje pliki, deletedponieważ usunąłem ten .git/indexplik

git reset

przejdź do resetowania

git status

sprawdź moją poprawkę

Uwaga: Kroki zaczynają się, gdy wylądowałem na tym pytaniu i użyłem odpowiedzi jako odniesienia.

Rozwiązałem to, usuwając różne puste pliki wykrywane przez git fsck, a następnie wykonując proste ściąganie git.

Rozczarowuje mnie to, że teraz, gdy nawet systemy plików implementują kronikowanie i inne techniki „transakcyjne”, aby utrzymać zdrowy rozsądek fs, git może dostać się do uszkodzonego stanu (i nie jest w stanie samodzielnie się odzyskać) z powodu awarii zasilania lub miejsca na urządzeniu.

Właśnie miałem ten sam problem: po wyciągnięciu odległego repozytorium, kiedy zrobiłem status git, dostałem: „błąd: plik obiektowy (...) jest pusty” „fatal: luźny obiekt (...) jest uszkodzony”

Sposób, w jaki to rozwiązałem, to:

1. git skrytka
2. usunięcie pliku git przez pomyłkę (nie jestem pewien, czy jest to konieczne)
3. git ukryć

Nie wiem dokładnie, co się stało, ale te instrukcje wydawały się czyścić wszystko.

Ponieważ muszę regularnie restartować maszynę wirtualną, więc ten problem zdarza mi się bardzo często. Po kilku razach zdałem sobie sprawę, że nie mogę powtórzyć procesu opisanego przez @ Nathan-Vanhoudnos za każdym razem, gdy tak się dzieje, chociaż zawsze działa. Potem wymyśliłem następujące szybsze rozwiązanie.

Krok 1

Przenieś całe repo do innego folderu.

mv current_repo temp_repo

Krok 2

Ponownie sklonuj repozytorium od początku.

git clone source_to_current_repo.git

Krok 3

Usuń wszystko w ramach nowego repozytorium oprócz folderu .git .

Krok 4

Przenieś wszystko z temp_repo do nowego repo poza tym .git folderu.

Krok 5

Usuń temp_repo i gotowe.

Po kilku latach jestem pewien, że możesz wykonać te procedury bardzo szybko.

1. mv twoja aplikacja do tworzenia kopii zapasowych, tj. mv app_folder app_folder_bk (jest jak skrytka git )
2. git sklonuj twoje_repository
3. Wreszcie,. Otwórz narzędzie do scalania (używam Linuksa Meld diff viewer lub Winmerge Windows) i skopiuj zmiany z prawej ( folder_aplikacji ) do lewej (nowy folder_aplikacji ) (jest to jak zastosowanie skrytki git ).

To wszystko. Może nie jest to najlepszy sposób, ale myślę, że jest tak praktyczny.

W moim przypadku ten błąd wystąpił, ponieważ pisałem komunikat zatwierdzenia, a mój notatnik został wyłączony.

Zrobiłem następujące kroki, aby naprawić błąd:

• git checkout -b backup-branch # Utwórz gałąź zapasową
• git reset --hard HEAD~4# Zresetuj do zatwierdzenia, gdzie wszystko działa dobrze. W moim przypadku musiałem cofnąć 4 zatwierdzenia w głowie, to znaczy do momentu, gdy moja głowa znajdzie się w punkcie przed wpisaniem komunikatu zatwierdzenia. Przed wykonaniem tego kroku, skopiuj skrót z resetów, które zresetujesz, w moim przypadku skopiowałem skrót z 4 ostatnich zatwierdzeń
• git cherry-pick <commit-hash> # Cherry wybiera zresetowane zatwierdzenia (w moim przypadku są to 4 zatwierdzenia, więc zrobiłem ten krok 4 razy) ze starej gałęzi do nowej gałęzi.
• git push origin backup-branch # Wciśnij nowy oddział, aby upewnić się, że wszystko działa dobrze
• git branch -D your-branch # Usuń gałąź lokalnie („twoja gałąź” to gałąź z problemem)
• git push origin :your-branch # Usuń gałąź ze zdalnego
• git branch -m backup-branch your-branch # Zmień nazwę gałęzi kopii zapasowej, aby miała nazwę gałęzi, w której wystąpił problem
• git push origin your-branch # Wciśnij nowy oddział
• git push origin :backup-branch # Usuń gałąź kopii zapasowej ze zdalnego

git stash
git checkout master
cd .git/ && find . -type f -empty -delete
git branch your-branch-name -D
git checkout -b your-branch-name
git stash pop

rozwiązać mój problem

Oto naprawdę prosty i szybki sposób na rozwiązanie tego problemu JEŻELI masz lokalne repozytorium ze wszystkimi gałęziami i zatwierdzeniami, których potrzebujesz, i jeśli nie masz nic przeciwko utworzeniu nowego repozytorium (lub usunięciu repozytorium serwera i utworzeniu nowej) Na swoim miejscu):

1. Utwórz nowe puste repozytorium na serwerze (lub usuń stare repozytorium i utwórz nowe na jego miejscu)
2. Zmień zdalny adres URL lokalnej kopii, aby wskazywał na zdalny adres URL nowego repozytorium.
3. Przekaż wszystkie gałęzie z lokalnego repozytorium do nowego repozytorium serwera.

Zachowuje to całą historię zatwierdzeń i gałęzie, które posiadałeś w lokalnym repozytorium.

Jeśli masz współpracowników przy repozytorium, to myślę, że w wielu przypadkach wszyscy twoi współpracownicy muszą zrobić również zmienić zdalny adres URL swojej lokalnej repozytorium i opcjonalnie wypchnąć wszelkie zatwierdzenia, których nie ma serwer.

To rozwiązanie działało dla mnie, gdy napotkałem ten sam problem. Miałem jednego współpracownika. Po przekazaniu mojego lokalnego repozytorium do nowego repozytorium zdalnego, po prostu zmienił swoje repozytorium lokalne, aby wskazywało na adres URL repozytorium zdalnego i wszystko działało dobrze.

Zakładam, że masz pilota ze wszystkimi istotnymi zmianami, które zostały już w nim wprowadzone. Nie przejmowałem się lokalnymi zmianami i po prostu chciałem uniknąć usuwania i ponownego klonowania dużego repozytorium. Jeśli masz ważne lokalne zmiany, możesz być bardziej ostrożny.

Miałem ten sam problem po awarii mojego laptopa. Prawdopodobnie dlatego, że było to duże repozytorium, miałem sporo uszkodzonych plików obiektowych, które pojawiały się pojedynczo podczas wywoływania git fsck --full, więc napisałem małą powłokę jednowierszową, aby automatycznie usunąć jeden z nich:

$ sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`

• 2>&1 przekierowuje komunikat o błędzie na standardowe wyjście, aby móc go grepować
• użyte opcje grep:
  • -o zwraca tylko tę część wiersza, która faktycznie pasuje
  • -E umożliwia zaawansowane wyrażenia regularne
  • -m 1 upewnij się, że zwracane jest tylko pierwsze dopasowanie
  • [0-9a-f]{2} dopasowuje dowolny ze znaków od 0 do 9 oraz a i f, jeśli dwa z nich występują razem
  • [0-9a-f]* dopasowuje dowolną liczbę znaków od 0 do 9 oraz a i f występujące razem

Nadal usuwa tylko jeden plik na raz, więc możesz wywołać go w pętli, np .:

$ while true; do sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`; done

Problem polega na tym, że nie generuje on nic użytecznego, więc nie wiesz, kiedy to się skończy (po prostu nie powinno nic robić pożytecznego po pewnym czasie)

Aby to naprawić, po prostu dodałem wywołanie git fsck --fullpo każdej rundzie w następujący sposób: $ while true; do sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`; git fsck --full; done

Jest teraz w przybliżeniu o połowę szybszy, ale generuje „stan”.

Potem bawiłem się kilkoma sugestiami w tym wątku i w końcu doszedłem do punktu, w którym mogłem git stashi git stash dropwiele zepsutych rzeczy.

pierwszy problem rozwiązany

Potem nadal miałem następujący problem: unable to resolve reference 'refs/remotes/origin/$branch': reference brokenktóry można rozwiązać $ rm \repo.git\refs\remotes\origin\$branch

$ git fetch

Potem zrobiłem $ git gc --prune=now

$ git remote prune origin

dla pewności i

git reflog expire --stale-fix --all

pozbyć się error: HEAD: invalid reflog entry $blubbpodczas biegania git fsck --full.

Przejdźmy do rzeczy prostych ... tylko w przypadku przesłania źródła do zdalnego repozytorium git

1. Utwórz kopię zapasową .git

2. sprawdź swojego dupka

   git fsck --full
   

3. usuń pusty plik obiektowy (wszystkie)

   rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e
   

4. sprawdź swojego gita ponownie.

   git fsck --full
   

5. wyciągnij źródło ze zdalnego gita

   git pull origin master
   

Często spotykam się z tym problemem z maszynami wirtualnymi.

Dla mnie następujące prace:

cd /path/to/your/project
rm -rf .git

Jeśli chcesz zaoszczędzić sobie trochę plików do pobrania - przejdź do eksploratora plików i usuń wszystkie pliki w folderze, które zostały już zatwierdzone, i pozostaw je w folderach / vendor i / node_modules (pracuję z kompozytorem i npm).

następnie po prostu utwórz nowe repozytorium

git init

dodaj swój pilot

git remote add origin ssh://git@github.com/YourUsername/repoName.git

i pobierz gałąź / wszystko

git fetch origin somebranch

i sprawdź to

git checkout somebranch

wtedy powinieneś być w punkcie przed błędem.

Mam nadzieję że to pomoże.

Pozdrowienia.

Napotykam ten sam problem i używam bardzo prostego sposobu, aby go naprawić. Odkryłem, że te brakujące pliki istniały na komputerze mojego kolegi z drużyny.

I kopiowane tych plików jeden po drugim do serwera git (9 plików Total), i że problem został rozwiązany.

Ja i moi koledzy kilkakrotnie zetknęliśmy się z tym samym problemem. Aby go rozwiązać, po prostu wykonujemy kroki opisane poniżej. Nie jest to najbardziej eleganckie rozwiązanie, jakie można znaleźć, ale działa bez utraty danych.

1. Zmień nazwę bieżącego katalogu roboczego. ( old_projectdla tego przykładu).
2. Sklonuj repozytorium w nowym katalogu za pomocą git clone.
3. W wierszu polecenia zmień katalog roboczy na nowo utworzony projekt i przejdź do gałęzi, nad którą pracujesz.
4. Skopiuj wszystkie pliki i katalogi z old_project(oprócz .gitkatalogu) do nowo utworzonego katalogu projektu.
5. Sprawdź status działającego drzewa (zauważ, że jest o wiele więcej zmian, niż się spodziewasz), a następnie zatwierdź zmiany.

Mam nadzieję, że to pomoże...

Oto sposób rozwiązania problemu, jeśli Twoje publiczne repo na github.com działa, ale Twoje lokalne repozytorium jest uszkodzone. Pamiętaj, że stracisz wszystkie zobowiązania, które zrobiłeś w lokalnym repozytorium.

W porządku, więc mam lokalnie jedno repozytorium, które mi to daje object empty error, i to samo repo na github.com, ale bez tego błędu. Więc po prostu sklonowałem repozytorium, które działa z github, a następnie skopiowałem wszystko z uszkodzonego repozytorium (oprócz folderu .git) i wkleiłem go, który działa.

To może nie być praktyczne rozwiązanie (ponieważ usuwasz lokalne zatwierdzenia), ale zachowujesz kod i naprawioną kontrolę wersji.

Pamiętaj, aby wykonać kopię zapasową przed zastosowaniem tego podejścia.

W moim przypadku nie było ważne, aby zachować lokalną historię zatwierdzeń. Jeśli więc dotyczy to Ciebie, możesz to zrobić jako szybką alternatywę dla powyższych rozwiązań:

Zasadniczo po prostu zamieniasz uszkodzony .git/katalog na czysty.

Załóżmy następujący katalog dla twojego projektu z uszkodzonym git: projects/corrupt_git/

1. cp projects/corrupt_git projects/backup - (opcjonalnie) wykonaj kopię zapasową
2. git clone [repo URL] projects/clean_git - żebyś dostał projects/clean_git
3. rm -rf corrupt_git/.git/ - usuń uszkodzony folder .git
4. mv clean_git/.git/ corrupt_git/ - przenieś czysty git do corrupt_git/.git
5. git statusw projects/corrupt_git- aby upewnić się, że zadziałało

Skopiuj wszystko (w folderze zawierającym .git) do kopii zapasowej, a następnie usuń wszystko i uruchom ponownie. Upewnij się, że masz pod ręką zdalny git:

git remote -v
 origin git@github.com:rwldrn/idiomatic.js.git (fetch)
 origin git@github.com:rwldrn/idiomatic.js.git (push)

Następnie

mkdir mygitfolder.backup
cp mygitfolder/* mygitfolder.backup/
cd mygitfolder
rm -r * .git*
git init
git remote add origin git@github.com:rwldrn/idiomatic.js.git

Następnie ręcznie scal wszystkie nowe pliki i staraj się, aby komputer był włączony.

Miałem ten sam problem po sprawdzeniu wzorca z czystej gałęzi. Po chwili rozpoznałem wiele zmodyfikowanych plików w master. Nie wiem, dlaczego tam byli, po przejściu z czystej gałęzi. W każdym razie, ponieważ zmodyfikowane pliki nie miały dla mnie sensu, po prostu je ukryłem i błąd zniknął.

git:(master) git stash

jeśli masz starą kopię zapasową i spiesz się:

Zrób NOWY KOPIĘ ZAPASOWEGO swojej bieżącej, uszkodzonej przez git ścieżki projektu.

1. przenieś .gitdo kosza (nigdy nie usuwaj)
2. skopiuj .gitz OLD kopii zapasowej
3. git pull (spowoduje konflikty scalania)
4. przenieś wszystkie swoje źródła (wszystko, co umieścisz w git) do kosza: ./src (nigdy nie usuwaj)
5. . skopiuj wszystkie źródła (wszystko, co umieścisz w git) z NOWEJ KOPII
6. akceptuj wszystkie „scalenia” git gui, pchaj i ... klaszcz w dłonie!

Przedstawione powyżej dwunastostopniowe rozwiązanie pomogło mi wydostać się z zacięcia. Dzięki. Kluczowe kroki to:

git fsck --full 

i usuń wszystkie puste obiekty

rm .git/objects/...

Następnie zdobycie dwóch linii bicza:

tail -n 2 .git/logs/refs/heads/master

Ze zwróconymi wartościami

git update-ref HEAD ...

W tym momencie nie miałem już żadnych błędów, więc wykonałem kopię zapasową moich najnowszych plików. Następnie wykonaj git pull, a następnie git push. Skopiowałem kopie zapasowe do pliku repozytorium git i wykonałem kolejne wypychanie git. To sprawiło, że jestem aktualny.

Naprawiłem błąd git: plik obiektowy jest pusty przez:

1. Zapisuję kopię wszystkich plików, które edytowałem od ostatniego udanego zatwierdzenia / wypchnięcia,
2. Usuwanie i ponowne klonowanie mojego repozytorium,
3. Zastępowanie starych plików moimi edytowanymi plikami.

Mam nadzieję, że to pomoże.

Zdarza mi się to również prawie regularnie. Nie stworzyłem protokołu, kiedy tak się dokładnie dzieje, ale podejrzewam, że pojawia się za każdym razem, gdy moja maszyna wirtualna istnieje „nieoczekiwanie”. Jeśli zamknę okno VM (używam Ubuntu 18.04) i zacznę od nowa, rzeczy zawsze (?) Działają. Ale jeśli okno maszyny Wirtualnej jest nadal otwarte, gdy mój laptop jest wyłączony (system hosta Windows), to dość często napotykam ten problem.

Co do wszystkich podanych tutaj odpowiedzi:

1. dziękuję - są bardzo przydatne; Zwykle zapisuję lokalną kopię mojego kodu, przywracam repo ze zdalnego i przenoszę kopię zapasową z powrotem do folderu lokalnego.

2. ponieważ podstawowy problem nie jest tak naprawdę problemem git, ale raczej kwestią VM i / lub Linuksa, zastanawiam się, czy nie powinno być sposobu, aby wyleczyć przyczynę, a raczej objawy? Czy ten rodzaj błędu nie oznacza, że ​​niektóre zmiany w systemie plików nie są „stosowane” w rozsądnym czasie, a jedynie buforowane? (patrz na przykład /unix/464184/are-file-edits-in-linux-directly-saved-into-disk ) - dla mnie wygląda to tak, jakby wirtualne maszyny Linux nie wystarczająco często synchronizuj swoje rzeczy. Niezależnie od tego, czy jest to kwestia VirtualBox firmy Oracle (która w przeciwnym razie działa bardzo dobrze), czy systemu plików gościa, czy też niektórych ustawień, które wszyscy przeoczamy. Byłbym jednak szczęśliwy, gdyby ktoś mógł rzucić na to światło.

Właściwie miałem ten sam problem. Przygotuj kopię swojego kodu przed wypróbowaniem tego.

właśnie zrobiłem git reset HEAD~

moje ostatnie zatwierdzenie zostało cofnięte, a następnie ponownie je zatwierdziłem, problem rozwiązany!

Ostrzeżenie: Z większym doświadczeniem zdaję sobie sprawę, że jest to opcja nuklearna i zwykle nie należy tego robić i niczego nie uczy. Jednak w rzadkich przypadkach dla osobistych projektów nadal uważam to za przydatne, więc zostawiam to.

Jeśli nie chcesz zachować swoich historycznych zobowiązań, po prostu biegnij

rm -r .git

Następnie odpowiedz „tak” na wszystkie pytania dotyczące usuwania plików chronionych przed zapisem. Problem rozwiązany w niecałą minutę.