Empuje de submodule Git

Si modifico un submodule, ¿puedo volver a enviar el compromiso al origen del submodule o necesitaría un clon? Si cloné, ¿puedo almacenar un clon dentro de otro repository?

Un submodule no es más que un clon de un repository git dentro de otro repository con algunos metadatos adicionales (input de tree de 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" 

Tenga en count que desde git1.7.11 ( [ANNOUNCE] Git 1.7.11.rc1 y release note , junio de 2012) se menciona:

" git push --recurse-submodules " aprendió a search opcionalmente en los historiales de los submodules vinculados al superproyecto y los expulsan.

Probablemente hecho después de este parche y la opción --on-demand :

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

Asegúrese de que todas las confirmaciones de submodules utilizadas por las revisiones que se enviarán estén disponibles en una sucursal de seguimiento remota.

  • Si se utiliza la check , se comprobará que todos los submodules confirmados que cambiaron en las revisiones que se enviarán están disponibles en un control remoto.
    De lo contrario, la inserción se cancelará y saldrá con un estado distinto de cero.
  • Si se usa on-demand , se presionarán todos los submodules que cambiaron en las revisiones que se presionarán.
    Si a pedido no pudo enviar todas las revisiones necesarias, también se cancelará y saldrá con un estado distinto de cero.

Así que puedes presionar todo de una vez con (desde el repository padre) a:

 git push --recurse-submodules=on-demand 

Esta opción solo funciona para un nivel de anidación. No se presionarán los cambios en el submodule dentro de otro submodule.


Con git 2.7 (enero de 2016), un simple empujón git será suficiente para impulsar el repository padre … y todos sus submodules.

Consulte commit d34141c , commit f5c7cd9 (03 de diciembre de 2015), commit f5c7cd9 (03 de diciembre de 2015) y commit b33a15b (17 de noviembre de 2015) de Mike Crowe ( mikecrowe ) .
(Fusionado por Junio ​​C Hamano – gitster – in commit 5d35d72 , 21 de diciembre de 2015)

push : añadir la opción de configuration recurseSubmodules

El parámetro de command-line --recurse-submodules ha existido durante un time, pero no tiene un file de configuration equivalente.

Siguiendo el estilo del parámetro correspondiente para git fetch , push.recurseSubmodules para proporcionar un valor pnetworkingeterminado para este parámetro.
Esto también requiere la adición de --recurse-submodules=no para permitir que la configuration se anule en la línea de command cuando sea necesario.

La forma más directa de implementar esto parece ser hacer push código de uso de push en submodule-config de una manera similar a fetch .

El documento de git config ahora incluye :

push.recurseSubmodules :

Asegúrese de que todas las confirmaciones de submodules utilizadas por las revisiones que se enviarán estén disponibles en una sucursal de seguimiento remoto.

  • Si el valor es ' check ', entonces Git verificará que todos los submodules confirmados que cambiaron en las revisiones que se enviarán están disponibles en al less un control remoto del submodule. Si falta alguna confirmación, la inserción se cancelará y saldrá con un estado distinto de cero.
  • Si el valor es ' on-demand ', se presionarán todos los submodules que cambiaron en las revisiones que se presionarán. Si a pedido no pudo enviar todas las revisiones necesarias, también se cancelará y saldrá con un estado distinto de cero. –
  • Si el valor es ' no ', el comportamiento pnetworkingeterminado es ignorar los submodules al retener.

Puede anular esta configuration en el momento de la inserción especificando ' --recurse-submodules=check|on-demand|no '.

Asi que:

 git config push.recurseSubmodules on-demand git push 

Git 2.12 (Q1 2017)

git push --dry-run --recurse-submodules=on-demand realmente funcionará.

Ver commit 0301c82 , commit 1aa7365 (17 Nov 2016) por Brandon Williams ( mbrandonw ) .
(Fusionado por Junio ​​C Hamano – gitster – in commit 12cf113 , 16 de diciembre de 2016)

push run with --dry-run realidad no (Git 2.11 Dec. 2016 e inferior / anterior) realiza una ejecución en seco cuando el command push está configurado para enviar submodules bajo demanda.
En cambio, todos los submodules que necesitan ser empujados son empujados a sus controles remotos, mientras que las actualizaciones para el superproyecto se realizan en modo de ejecución en seco.
Este es un error y no el comportamiento previsto de un funcionamiento en seco.

Enseñe push para respetar la opción --dry-run cuando está configurado para empujar recursivamente submodules 'a pedido'.
Esto se hace pasando el --dry-run al process hijo que realiza un push para un submodule cuando se ejecuta en seco.


Y aún en Git 2.12, ahora --recurse-submodules=only " --recurse-submodules=only " para expulsar submodules sin presionar el superproyecto de nivel superior .

Consulte commit 225e8bf , commit 6c656c3 , commit 14c01bd (19 de diciembre de 2016) por Brandon Williams ( mbrandonw ) .
(Fusionado por Junio ​​C Hamano – gitster – in commit 792e22e , 31 ene 2017)