Git submodule push

Se modifico un sottomodulo, posso riportare il commit all’origine del sottomodulo o richiedere un clone? Se clone, posso memorizzare un clone in un altro repository?

Un sottomodulo non è altro che un clone di un repository git all’interno di un altro repository con alcuni metadati extra (voce gitlink tree, file .gitmodules)

 $ cd your_submodule $ git checkout master  $ git commit -a -m "commit in submodule" $ git push $ cd .. $ git add your_submodule $ git commit -m "Updated submodule" 

Si noti che poiché git1.7.11 ( [ ANNOUNCE ] Git 1.7.11.rc1 e note di rilascio , giugno 2012) menziona:

git push --recurse-submodules ” ha imparato a esaminare facoltativamente le storie dei sottomoduli legati al superprogetto e li spinge fuori.

Probabilmente fatto dopo questa patch e l’opzione --on-demand :

 recurse-submodules=:: 

Assicurarsi che tutti i commit del submodule utilizzati dalle revisioni da spingere siano disponibili su un ramo di monitoraggio remoto.

  • Se viene utilizzato il check , verrà verificato che tutti i commit di submodule modificati nelle revisioni da spingere siano disponibili su un telecomando.
    In caso contrario, la spinta verrà interrotta e uscire con uno stato diverso da zero.
  • Se viene utilizzato on-demand , verranno inviati tutti i sottomoduli modificati nelle revisioni da spingere.
    Se on-demand non è stato in grado di inviare tutte le revisioni necessarie, verrà interrotto e verrà chiuso con uno stato diverso da zero.

Quindi puoi spingere tutto in una volta con (dal repository padre) a:

 git push --recurse-submodules=on-demand 

Questa opzione funziona solo per un livello di nidificazione. Le modifiche al sottomodulo all’interno di un altro sottomodulo non verranno inserite.


Con git 2.7 (gennaio 2016), un semplice push git sarà sufficiente per spingere il repository padre … e tutti i suoi sottomoduli.

Vedere commit d34141c , commit f5c7cd9 (03 dic 2015), commit f5c7cd9 (03 dic 2015) e commit b33a15b (17 nov 2015) di Mike Crowe ( mikecrowe ) .
(Fuso da Junio ​​C Hamano – gitster – in commit 5d35d72 , 21 dic 2015)

push : aggiungi l’opzione di configurazione recurseSubmodules

Il parametro della riga di comando --recurse-submodules esiste da un po ‘di tempo ma non ha alcun file di configurazione equivalente.

Seguendo lo stile del parametro corrispondente per git fetch , push.recurseSubmodules per fornire un valore predefinito per questo parametro.
Ciò richiede anche l’aggiunta di --recurse-submodules=no per consentire la sovrascrittura della configurazione sulla riga di comando quando richiesto.

Il modo più semplice per implementarlo sembra essere quello di far utilizzare il codice push in submodule-config in un modo simile per fetch .

Il git config doc ora include :

push.recurseSubmodules :

Assicurati che tutti i commit del submodule utilizzati dalle revisioni da spingere siano disponibili su un ramo di monitoraggio remoto.

  • Se il valore è ‘ check ‘, Git verificherà che tutti i commit di submodule modificati nelle revisioni da spingere siano disponibili su almeno un remoto del submodule. Se mancano dei commit, il push verrà interrotto e uscirà con uno stato diverso da zero.
  • Se il valore è ” on-demand “, verranno inviati tutti i sottomoduli modificati nelle revisioni da spingere. Se on-demand non è stato in grado di inviare tutte le revisioni necessarie, verrà interrotto e verrà chiuso con uno stato diverso da zero. –
  • Se il valore è ” no “, il comportamento predefinito di ignorare i sottomoduli quando viene premuto viene mantenuto.

È ansible sovrascrivere questa configurazione al momento --recurse-submodules=check|on-demand|no specificando ‘ --recurse-submodules=check|on-demand|no ‘.

Così:

 git config push.recurseSubmodules on-demand git push 

Git 2.12 (primo trimestre 2017)

git push --dry-run --recurse-submodules=on-demand funzionerà davvero.

Vedi commit 0301c82 , commit 1aa7365 (17 nov 2016) di Brandon Williams ( mbrandonw ) .
(Fuso da Junio ​​C Hamano – gitster – in commit 12cf113 , 16 dic 2016)

push run with --dry-run realtà non è (Git 2.11 Dic. 2016 e precedenti / precedenti) esegue un dry-run quando push è configurato per inviare i sottomoduli su richiesta.
Invece tutti i sottomoduli che devono essere spinti vengono effettivamente spinti ai loro telecomandi, mentre gli eventuali aggiornamenti per il superprogetto vengono eseguiti come una prova a secco.
Questo è un bug e non il comportamento previsto di una corsa a secco.

Insegnare a push a rispettare l’ --dry-run quando configurato per inviare in modo ricorsivo i sottomoduli “su richiesta”.
Questo viene fatto passando il flag --dry-run al processo figlio che esegue un push per un sottomodulo quando esegue un dry-run.


E ancora in Git 2.12, ora hai l’opzione ” --recurse-submodules=onlyper spingere i sottomoduli senza spingere il superprogetto di primo livello .

Vedi commit 225e8bf , commit 6c656c3 , commit 14c01bd (19 dic 2016) di Brandon Williams ( mbrandonw ) .
(Fuso da Junio ​​C Hamano – gitster – in commit 792e22e , 31 gen 2017)