Git submodule push

Si modifico un submódulo, ¿puedo devolver el commit al origen del submódulo, o eso requeriría un clon? Si es un clon, ¿puedo almacenar un clon dentro de otro repositorio?

Un submódulo no es más que un clon de un repositorio de git dentro de otro repositorio con algunos metadatos adicionales (entrada de árbol de gitlink, archivo .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 cuenta que desde git1.7.11 ( [ANUNCIO] Git 1.7.11.rc1 y la nota de lanzamiento , junio de 2012) menciona:

" git push --recurse-submodules" aprendió a buscar opcionalmente en las historias de submódulos unidos al superproyecto y expulsarlos.

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

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

Asegúrese de que todas las confirmaciones de submódulo utilizadas por las revisiones que se enviarán estén disponibles en una rama de seguimiento remoto.

• Si checkse usa, se verificará que todos los commits de submódulos que cambiaron en las revisiones que se enviarán estén disponibles en un remoto.
  De lo contrario, el empuje se abortará y saldrá con un estado distinto de cero.
• Si on-demandse usa, todos los submódulos que cambiaron en las revisiones que se enviarán serán empujados.
  Si a pedido no pudo impulsar todas las revisiones necesarias, también se cancelará y saldrá con un estado distinto de cero.

Entonces, podría empujar todo de una vez con (del repositorio principal) a:

git push --recurse-submodules=on-demand

Esta opción solo funciona para un nivel de anidamiento. Los cambios en el submódulo dentro de otro submódulo no se enviarán.

Con git 2.7 (enero de 2016), un simple git push será suficiente para impulsar el repositorio principal ... y todos sus submódulos.

Ver commit d34141c , commit f5c7cd9 (03 dic 2015), commit f5c7cd9 (03 dic 2015) y commit b33a15b (17 nov 2015) por Mike Crowe ( mikecrowe) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 5d35d72 , 21 dic 2015)}

push: agregar la recurseSubmodulesopción de configuración

El --recurse-submodulesparámetro de línea de comando ha existido por algún tiempo pero no tiene un archivo de configuración equivalente.

Siguiendo el estilo del parámetro correspondiente para git fetch, inventemos push.recurseSubmodulesproporcionar un valor predeterminado para este parámetro.
Esto también requiere la adición de --recurse-submodules=nopara permitir que la configuración se anule en la línea de comando cuando sea necesario.

La forma más sencilla de implementar esto parece ser pushusar el código de submodule-configmanera similar a fetch.

El git configdocumento ahora incluye :

push.recurseSubmodules:

Asegúrese de que todas las confirmaciones de submódulo utilizadas por las revisiones que se enviarán estén disponibles en una rama de seguimiento remoto.

• Si el valor es ' check', Git verificará que todas las confirmaciones de submódulo que cambiaron en las revisiones que se enviarán estén disponibles en al menos un control remoto del submódulo. Si falta alguna confirmación, la inserción se cancelará y saldrá con un estado distinto de cero.
• Si el valor es ' on-demand', todos los submódulos que cambiaron en las revisiones que se enviarán serán empujados. Si a pedido no pudo impulsar todas las revisiones necesarias, también se cancelará y saldrá con un estado distinto de cero. -
• Si el valor es ' no', se conserva el comportamiento predeterminado de ignorar submódulos al empujar.

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

Entonces:

git config push.recurseSubmodules on-demand
git push

Git 2.12 (Q1 2017)

git push --dry-run --recurse-submodules=on-demand en realidad funcionará

Ver commit 0301c82 , commit 1aa7365 (17 de noviembre de 2016) por Brandon Williams ( mbrandonw) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 12cf113 , 16 dic 2016)}

push run with --dry-runen realidad (Git 2.11, diciembre de 2016 y versiones anteriores / anteriores) realiza una ejecución en seco cuando push está configurado para enviar submódulos a pedido.
En cambio, todos los submódulos que necesitan ser empujados son empujados a sus controles remotos, mientras que cualquier actualización para el superproyecto se realiza como una ejecución en seco.
Este es un error y no el comportamiento previsto de una ejecución en seco.

Enseñe pusha respetar la --dry-runopción cuando esté configurado para empujar recursivamente submódulos 'a pedido'.
Esto se hace pasando la --dry-runbandera al proceso hijo que realiza una inserción de submódulos al realizar una ejecución en seco.

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

Ver commit 225e8bf , commit 6c656c3 , commit 14c01bd (19 dic 2016) por Brandon Williams ( mbrandonw) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 792e22e , 31 ene 2017)}