Ho un progetto con un sottomodulo che punta a un commit non valido: il commit del sottomodulo è rimasto locale e quando provo a recuperarlo da un altro repository ottengo:

$ git submodule update
fatal: reference is not a tree: 2d7cfbd09fc96c04c4c41148d44ed7778add6b43
Unable to checkout '2d7cfbd09fc96c04c4c41148d44ed7778add6b43' in submodule path 'mysubmodule'

So cosa TESTA modulo dovrebbe essere, c'è un modo per cambiare questo a livello locale, senza spingere dal repo che fa hanno commettere 2d7cfbd09fc96c04c4c41148d44ed7778add6b43?

Non sono sicuro di essere chiaro ... ecco una situazione simile che ho trovato.

Supponendo che il repository del sottomodulo contenga un commit che si desidera utilizzare (diversamente dal commit a cui fa riferimento lo stato corrente del super-progetto), ci sono due modi per farlo.

Il primo richiede di conoscere già il commit dal sottomodulo che si desidera utilizzare. Funziona da "dentro, fuori" regolando direttamente il sottomodulo e quindi aggiornando il super-progetto. Il secondo funziona dall'esterno, trovando il commit del super-progetto che ha modificato il sottomodulo e quindi reimpostando l'indice del super-progetto per fare riferimento a un diverso commit del sottomodulo.

Alla rovescia

Se sai già che impegnano si desidera che il modulo per l'uso, cdal modulo, controllare il impegnano desiderato, quindi git adde git commitindietro nel super-progetto.

Esempio:

$ git submodule update
fatal: reference is not a tree: e47c0a16d5909d8cb3db47c81896b8b885ae1556
Unable to checkout 'e47c0a16d5909d8cb3db47c81896b8b885ae1556' in submodule path 'sub'

Spiacenti, qualcuno ha eseguito un commit di super-progetto che fa riferimento a un commit non pubblicato nel sottomodulo sub. In qualche modo, sappiamo già che vogliamo che il sottomodulo sia in commit 5d5a3ee314476701a20f2c6ec4a53f88d651df6c. Vai lì e dai un'occhiata direttamente.

Acquista nel sottomodulo

$ cd sub
$ git checkout 5d5a3ee314476701a20f2c6ec4a53f88d651df6c
Note: moving to '5d5a3ee314476701a20f2c6ec4a53f88d651df6c' which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
  git checkout -b <new_branch_name>
HEAD is now at 5d5a3ee... quux
$ cd ..

Dal momento che stiamo verificando un commit, questo produce un HEAD distaccato nel sottomodulo. Se si desidera assicurarsi che il sottomodulo stia utilizzando un ramo, utilizzare git checkout -b newbranch <commit>per creare e verificare un ramo al commit o verificare il ramo desiderato (ad es. Uno con il commit desiderato in punta).

Aggiorna il Super-progetto

Un checkout nel sottomodulo si riflette nel super-progetto come una modifica all'albero di lavoro. Quindi dobbiamo mettere in scena il cambiamento nell'indice del super-progetto e verificare i risultati.

$ git add sub

Controlla i risultati

$ git submodule update
$ git diff
$ git diff --cached
diff --git c/sub i/sub
index e47c0a1..5d5a3ee 160000
--- c/sub
+++ i/sub
@@ -1 +1 @@
-Subproject commit e47c0a16d5909d8cb3db47c81896b8b885ae1556
+Subproject commit 5d5a3ee314476701a20f2c6ec4a53f88d651df6c

L'aggiornamento del sottomodulo era silenzioso perché il sottomodulo è già al commit specificato. Il primo diff mostra che l'indice e il worktree sono uguali. Il terzo diff mostra che l'unica modifica a fasi è lo spostamento del subsottomodulo su un commit diverso.

Commettere

git commit

Ciò commette la voce del sottomodulo fissa.

Fuori dentro

Se non si è sicuri del commit da utilizzare dal sottomodulo, è possibile consultare la cronologia nel superprogetto per guidare l'utente. Puoi anche gestire il reset direttamente dal super-progetto.

$ git submodule update
fatal: reference is not a tree: e47c0a16d5909d8cb3db47c81896b8b885ae1556
Unable to checkout 'e47c0a16d5909d8cb3db47c81896b8b885ae1556' in submodule path 'sub'

Questa è la stessa situazione di cui sopra. Ma questa volta ci concentreremo sul ripararlo dal super-progetto anziché immergerlo nel sottomodulo.

Trova Errant Commit del Super-progetto

$ git log --oneline -p -- sub
ce5d37c local change in sub
diff --git a/sub b/sub
index 5d5a3ee..e47c0a1 160000
--- a/sub
+++ b/sub
@@ -1 +1 @@
-Subproject commit 5d5a3ee314476701a20f2c6ec4a53f88d651df6c
+Subproject commit e47c0a16d5909d8cb3db47c81896b8b885ae1556
bca4663 added sub
diff --git a/sub b/sub
new file mode 160000
index 0000000..5d5a3ee
--- /dev/null
+++ b/sub
@@ -0,0 +1 @@
+Subproject commit 5d5a3ee314476701a20f2c6ec4a53f88d651df6c

OK, sembra che sia andato male ce5d37c, quindi ripristineremo il sottomodulo dal suo genitore ( ce5d37c~).

In alternativa, puoi prendere il commit del sottomodulo dal testo della patch ( 5d5a3ee314476701a20f2c6ec4a53f88d651df6c) e usare invece il processo "dentro, fuori" sopra.

Acquista nel Super-progetto

$ git checkout ce5d37c~ -- sub

Ciò ha reimpostato la voce del sottomodulo per subciò che era in commit ce5d37c~nel super-progetto.

Aggiorna il sottomodulo

$ git submodule update
Submodule path 'sub': checked out '5d5a3ee314476701a20f2c6ec4a53f88d651df6c'

L'aggiornamento del sottomodulo è andato bene (indica una HEAD staccata).

Controlla i risultati

$ git diff ce5d37c~ -- sub
$ git diff
$ git diff --cached
diff --git c/sub i/sub
index e47c0a1..5d5a3ee 160000
--- c/sub
+++ i/sub
@@ -1 +1 @@
-Subproject commit e47c0a16d5909d8cb3db47c81896b8b885ae1556
+Subproject commit 5d5a3ee314476701a20f2c6ec4a53f88d651df6c

Il primo diff mostra che subora è lo stesso in ce5d37c~. Il secondo diff mostra che l'indice e il worktree sono uguali. Il terzo diff mostra che l'unica modifica a fasi è lo spostamento del subsottomodulo in un diverso commit.

Commettere

git commit

Ciò commette la voce del sottomodulo fissa.

prova questo:

git submodule sync
git submodule update

Questo errore può indicare che manca un commit nel sottomodulo. Cioè, il repository (A) ha un sottomodulo (B). A vuole caricare B in modo che indichi un certo commit (in B). Se quel commit è in qualche modo mancante, otterrai quell'errore. Una volta possibile causa: il riferimento al commit è stato inserito in A, ma il commit effettivo non è stato inviato da B. Quindi inizierei da lì.

Meno probabilmente, c'è un problema con le autorizzazioni e il commit non può essere tirato (possibile se stai usando git + ssh).

Assicurati che i percorsi dei sottomoduli appaiano bene in .git / config e .gitmodules.

Un'ultima cosa da provare - all'interno della directory del sottomodulo: git reset HEAD --hard

Causa possibile

Questo può succedere quando:

1. I sottomoduli sono stati modificati sul posto
2. Sottomodulo (i) sottoposto a commit, che aggiorna l'hash del sottomodulo indicato
3. Sottomodulo (i) non inviato .

ad esempio qualcosa di simile è successo:

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

A questo punto avrebbe dovuto spingere il sottomodulo.

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

Di conseguenza, gli commit mancanti non possono essere trovati dall'utente remoto perché si trovano ancora sul disco locale.

Soluzione

Informa la persona che ha modificato il sottomodulo per inviare, ad es

$ cd submodule
$ git push

Ho ricevuto questo errore quando ho fatto:

$ git submodule update --init --depth 1

ma il commit nel progetto principale puntava a un commit precedente.

Eliminazione della cartella del sottomodulo ed esecuzione:

$ git submodule update --init

NON ha risolto il problema. Ho eliminato il repository e riprovato senza il flag di profondità e ha funzionato.

Questo errore si verifica in Ubuntu 16.04 git 2.7.4, ma non in Ubuntu 18.04 git 2.17, TODO trova il commit o la versione esatti.

Questo può accadere anche quando si ha un sottomodulo che punta a un repository che è stato ridisegnato e il commit dato è "sparito". Mentre il commit potrebbe essere ancora nel repository remoto, non si trova in un ramo. Se non riesci a creare un nuovo ramo (ad es. Non il tuo repository), sei bloccato con la necessità di aggiornare il super progetto per puntare a un nuovo commit. In alternativa puoi spingere una delle tue copie dei sottomoduli altrove e quindi aggiornare il super-progetto in modo che punti a quel repository.

La tua filiale potrebbe non essere aggiornata, una soluzione semplice ma prova git fetch

Questa risposta è per gli utenti di SourceTree con esperienza git terminale limitata.

Aprire il sottomodulo problematico dall'interno del progetto Git (superprogetto).

Recupera e assicurati che "Recupera tutti i tag" sia selezionato.

Rebase tira il tuo progetto Git.

Ciò risolverà il problema "riferimento non è un albero" 9 su dieci volte. Quella volta che non lo farà, è una correzione terminale come descritto dalla risposta principale.

La cronologia del tuo sottomodulo viene comunque conservata in modo sicuro nel git del sottomodulo.

Quindi, perché non eliminare semplicemente il sottomodulo e aggiungerlo di nuovo?

Altrimenti, hai provato a modificare manualmente HEADo refs/master/headall'interno del sottomodulo.git

Per sicurezza, prova ad aggiornare i tuoi gitbinari.

GitHub per Windows ha la versione git version 1.8.4.msysgit.0che nel mio caso era il problema. Aggiornamento risolto.

Nel mio caso, nessuna delle risposte sopra risolve il problema anche se sono buone risposte. Quindi inserisco la mia soluzione (nel mio caso ci sono due client git, client A e B):

1. vai alla directory del sottomodulo:

   cd sub
   

2. checkout per padroneggiare:

   git checkout master
   

3. rifare ad un codice di commit che entrambi i client possono vedere

4. tornare alla directory del genitore:

5. impegnarsi a padroneggiare

6. passare all'altro client ， fare di rebasenuovo.

7. finalmente funziona bene ora! Forse perde un paio di commit ma funziona.

8. Cordiali saluti, non tentare di rimuovere il sottomodulo, rimarrà .git/moduleslì e non potrà rileggere nuovamente questo sottomodulo, se non quello locale reattivo.

Per sincronizzare il repository git con la testa del sottomodulo, nel caso sia proprio quello che vuoi, ho scoperto che rimuovere il sottomodulo e poi leggerlo evita di armeggiare con la cronologia. Sfortunatamente la rimozione di un sottomodulo richiede l'hacking piuttosto che essere un singolo comando git, ma fattibile.

I passaggi che ho seguito per rimuovere il sottomodulo, ispirato a https://gist.github.com/kyleturner/1563153 :

1. Esegui git rm --cached
2. Elimina le righe pertinenti dal file .gitmodules.
3. Elimina la sezione pertinente da .git / config.
4. Elimina i file del sottomodulo ora non tracciati.
5. Rimuovere la directory .git / modules /

Ancora una volta, questo può essere utile se tutto ciò che vuoi è puntare di nuovo alla testa del sottomodulo e non hai complicato le cose, avendo bisogno di mantenere intatta la copia locale del sottomodulo. Presuppone che tu abbia il sottomodulo "giusto" come proprio repository, dovunque sia l'origine, e vuoi solo tornare a includerlo correttamente come sottomodulo.

Nota: crea sempre una copia completa del tuo progetto prima di iniziare questo tipo di manipolazione o qualsiasi comando git oltre al semplice commit o push. Lo consiglierei anche con tutte le altre risposte e come linea guida generale.

Mi sono appena imbattuto in questo problema e nessuna di queste soluzioni ha funzionato per me. Quello che si è rivelato essere la soluzione al mio problema è in realtà molto più semplice: aggiorna Git. Il mio era 1.7.1 e dopo averlo aggiornato a 2.16.1 (più recente), il problema è scomparso senza lasciare traccia! Immagino che lo lascerò qui, spero che aiuti qualcuno.