Git push sottomodule

Se modifico un sottomodulo, posso riportare il commit all'origine del sottomodulo o richiederebbe un clone? Se clone, posso archiviare un clone all'interno di un altro repository?

Un sottomodulo non è altro che un clone di un repository git all'interno di un altro repository con alcuni metadati aggiuntivi (voce dell'albero gitlink, file .gitmodules)

$ cd your_submodule
$ git checkout master
<hack,edit>
$ git commit -a -m "commit in submodule"
$ git push
$ cd ..
$ git add your_submodule
$ git commit -m "Updated submodule"

Si noti che dal momento che git1.7.11 ( [ ANNOUNCE ] Git 1.7.11.rc1 e nota di rilascio , giugno 2012) menziona:

" git push --recurse-submodules" ho imparato a esaminare opzionalmente la storia dei sottomoduli legati al superprogetto e a spingerli fuori.

Probabilmente fatto dopo questa patch e l' --on-demandopzione:

recurse-submodules=<check|on-demand>::

Assicurarsi che tutti i commit del sottomodulo utilizzati dalle revisioni da inviare siano disponibili su un ramo di tracciamento remoto.

• Se checkutilizzato, verrà verificato che tutti i commit del sottomodulo che sono stati modificati nelle revisioni da inviare siano disponibili su un telecomando.
  Altrimenti la pressione verrà interrotta e uscirà con uno stato diverso da zero.
• Se on-demandutilizzato, verranno inviati tutti i sottomoduli che sono stati modificati nelle revisioni da inviare.
  Se on-demand non è stato in grado di inviare tutte le revisioni necessarie, verrà anche interrotto e uscirà con uno stato diverso da zero.

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

git push --recurse-submodules=on-demand

Questa opzione funziona solo per un livello di annidamento. Le modifiche al sottomodulo all'interno di un altro sottomodulo non verranno inviate.

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

Vedi commit d34141c , commit f5c7cd9 (03 dic 2015), commit f5c7cd9 (03 dic 2015) e commit b33a15b (17 nov 2015) di Mike Crowe ( mikecrowe) .
^{(Unita da Junio ​​C Hamano - gitster- in commit 5d35d72 , 21 dic 2015)}

push: aggiungi l' recurseSubmodulesopzione di configurazione

Il --recurse-submodulesparametro della riga di comando esiste da un po 'di tempo ma non ha un equivalente del file di configurazione.

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

Il modo più semplice per implementare questo sembra essere quello di pushutilizzare il codice in submodule-configmodo simile a fetch.

Il git configdocumento ora include :

push.recurseSubmodules:

Assicurarsi che tutti i commit del sottomodulo utilizzati dalle revisioni da inviare siano disponibili in un ramo di tracciamento remoto.

• Se il valore è " check", Git verificherà che tutti i commit del sottomodulo che sono stati modificati nelle revisioni da inviare siano disponibili su almeno un telecomando del sottomodulo. 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 che sono stati modificati nelle revisioni da inviare. Se on-demand non è stato in grado di inviare tutte le revisioni necessarie, verrà anche interrotto e uscirà con uno stato diverso da zero. -
• Se il valore è " no", il comportamento predefinito di ignorare i sottomoduli quando viene mantenuto lo push.

È possibile ignorare questa configurazione al momento del push specificando ' --recurse-submodules=check|on-demand|no'.

Così:

git config push.recurseSubmodules on-demand
git push

Git 2.12 (Q1 2017)

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

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

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

Insegnare pusha rispettare l' --dry-runopzione quando configurato per spingere in modo ricorsivo i sottomoduli "su richiesta".
Questo viene fatto passando la --dry-runbandiera al processo figlio che esegue una spinta per un sottomodulo quando si esegue una corsa a secco.

E ancora in Git 2.12, ora hai l' --recurse-submodules=onlyopzione " " per espellere i sottomoduli senza spingere il superprogetto di livello superiore .

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