Spróbuj tego:

git submodule sync
git submodule update

Ten błąd może oznaczać brak commita w podmodule. Oznacza to, że repozytorium (A) ma podmoduł (B). A chce wczytać B tak, aby wskazywało na określony commit (w B). Jeśli w jakiś sposób brakuje tego commita, otrzymasz ten błąd. Po ewentualnej przyczynie: odniesienie do commita zostało wypchnięte W A, ale rzeczywisty commit nie został wypchnięty z B. więc zacznę od tego.

Mniej prawdopodobne, że występuje problem z uprawnieniami, a commit nie może zostać wyciągnięty (możliwe, jeśli używasz git+ssh).

Upewnij się, że ścieżki podmodułu wyglądają dobrze .git / config i .gitmodules.

Jeszcze jedna rzecz do wypróbowania-wewnątrz katalogu podmodułów: git reset HEAD --hard

Możliwa przyczyna

Może się to zdarzyć, gdy:

1. Submodule zostały edytowane w miejscu
2. submodule(s) committed, które aktualizują hash podmodułu wskazywanego na
3. Submodule(S) nie wypychane.

Np. stało się coś takiego:

$ cd submodule
$ emacs my_source_file  # edit some file(s)
$ git commit -am "Making some changes but will forget to push!"

Powinien mieć podmoduł popchnięty w tym momencie.

$ cd .. # back to parent repository
$ git commit -am "updates to parent repository"
$ git push origin master

W rezultacie, brakujące commity nie mogą być znalezione przez zdalnego użytkownika, ponieważ są nadal na dysku lokalnym.

Rozwiązanie

Informuje osobę, która zmodyfikowała podmoduł do push, czyli

$ cd submodule
$ git push

Dostałem ten błąd kiedy to zrobiłem:

$ git submodule update --init --depth 1

Ale commit w projekcie nadrzędnym wskazywał na wcześniejszy commit.

Usunięcie folderu podmodułu i uruchomienie:

$ git submodule update --init

Ten błąd występuje w Ubuntu 16.04 git 2.7.4, ale nie w Ubuntu 18.04 git 2.17, aby znaleźć dokładne poprawki lub wersję.

Twoja branża może nie być aktualna, proste rozwiązanie, ale spróbuj git fetch

Może się to zdarzyć również wtedy, gdy masz podmoduł wskazujący na repozytorium, które zostało zrebasowane, a dany commit "zniknął". Chociaż commit może nadal znajdować się w zdalnym repozytorium, nie znajduje się w gałęzi. Jeśli nie możesz utworzyć nowej gałęzi (np. Nie twojego repozytorium), musisz zaktualizować super projekt, aby wskazać nowy commit. Alternatywnie możesz wypchnąć jedną z kopii podmodułów gdzie indziej, a następnie zaktualizować super-projekt, aby wskazać to repozytorium.

Ta odpowiedź jest dla użytkowników SourceTree z ograniczonym doświadczeniem w obsłudze terminala git.

Otwórz problematyczny podmoduł wewnątrz projektu Git (super-projekt).

Fetch i upewnij się, że zaznaczono 'Fetch all tags'.

Rebase pull your Git project.

To rozwiąże problem "reference is not a tree" 9 na 10 razy. Ten 1 raz nie będzie, jest poprawką terminala, jak opisano w górnej odpowiedzi.

Historia twojego submodule jest bezpiecznie zachowana w submodule git.

Więc dlaczego po prostu nie usunąć podmodułu i dodać go ponownie?

W Przeciwnym Razie, czy próbowałeś ręcznie edytować HEAD LUB refs/master/head w podmodule .git

Dla pewności spróbuj zaktualizować swoje git pliki binarne.

GitHub Dla Windows ma wersję git version 1.8.4.msysgit.0, która w moim przypadku była problemem. Aktualizacja rozwiązała problem.

W moim przypadku żadna z powyższych odpowiedzi nie rozwiązuje problemu, nawet jeśli są to dobre odpowiedzi. Więc zamieszczam moje rozwiązanie (w moim przypadku są dwa klienty git, klient a i B):

1. Idź do submodule ' s dir:

   cd sub
   

2. Checkout do mistrza:

   git checkout master
   

3. Rebase do kodu zatwierdzającego, który może zobaczyć zarówno klient

4. Wróć do katalogu rodzica:

5. Commit to master

6. Zmiana na innego klienta， do rebase jeszcze raz.

7. Wreszcie działa dobrze teraz! Może stracić kilka commitów, ale to działa.

8. Dla twojej wiadomości, nie próbuj usuwać submodułu, pozostanie tam .git/modules i nie będzie mógł ponownie odczytać tego submodułu, chyba że będzie reaktywny lokalny.

Aby zsynchronizować Git repo z głowicą submodule, na wypadek, gdyby naprawdę tego chcesz, odkryłem, że usunięcie submodule, a następnie odczytanie go pozwala uniknąć majstrowania w historii. Niestety usunięcie podmodułu wymaga raczej hackingu niż pojedynczego polecenia git, ale wykonalnego.

Kroki, które wykonałem, aby usunąć podmoduł, zainspirowany https://gist.github.com/kyleturner/1563153 :

1. Uruchom git RM --cached
2. Usuń odpowiednie wiersze z .plik gitmodules.
3. skreślić odpowiednią sekcję z .git / config.
4. Usuń teraz nie śledzone pliki podrzędne.
5. Usuń katalog .git / modules /

Ponownie, może to być przydatne, jeśli wszystko, co chcesz, to ponownie skierować na głowę submodule, a nie skomplikowałeś rzeczy, potrzebując zachowania lokalnej kopii submodule w stanie nienaruszonym. Zakłada, że masz podmoduł "prawo" jako własne repo, gdziekolwiek jest jego pochodzenie, i po prostu chcesz wrócić do prawidłowo włączając go jako podmoduł.

Uwaga: zawsze wykonuj pełną kopię swojego projektu przed rozpoczęciem tego rodzaju manipulacji lub jakichkolwiek poleceń git poza prostym zatwierdzeniem lub push. Radziłbym to również przy wszystkich innych odpowiedziach i jako ogólne wytyczne dla Gita.

Właśnie natknąłem się na ten problem i Żadne z tych rozwiązań nie zadziałało na mnie. To, co okazało się rozwiązaniem dla mojego problemu, jest o wiele prostsze: upgrade Git. Mój był 1.7.1, a po uaktualnieniu go do 2.16.1 (najnowszy), problem zniknął bez śladu! Chyba go tu zostawiam, mam nadzieję, że komuś pomoże.