Push do submódulo Git

Se eu modificar um submódulo, posso enviar a confirmação de volta à origem do submódulo ou isso exigiria um clone? Se clone, posso armazenar um clone dentro de outro repositório?

Um submódulo nada mais é do que um clone de um repositório git dentro de outro repositório com alguns metadados extras (entrada em árvore gitlink, arquivo .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"

Observe que desde o git1.7.11 ( [ ANUNCIAR ] Git 1.7.11.rc1 e nota de lançamento , junho de 2012) menciona:

" git push --recurse-submodules" aprendeu a examinar opcionalmente os históricos dos submódulos vinculados ao superprojeto e empurrá-los para fora.

Provavelmente feito após este patch e a --on-demandopção:

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

Verifique se todos os commits do submódulo usados ​​pelas revisões a serem enviadas estão disponíveis em uma ramificação de rastreamento remoto.

• Se checkfor usado, será verificado se todos os commit do submódulo que foram alterados nas revisões a serem enviadas estão disponíveis em um controle remoto.
  Caso contrário, o push será abortado e sairá com status diferente de zero.
• Se on-demandfor usado, todos os submódulos que foram alterados nas revisões a serem enviadas serão enviados.
  Se a demanda não puder enviar todas as revisões necessárias, ela também será abortada e sairá com status diferente de zero.

Assim, você pode enviar tudo de uma só vez com (do repositório pai) a:

git push --recurse-submodules=on-demand

Esta opção funciona apenas para um nível de aninhamento. Alterações no submódulo dentro de outro submódulo não serão enviadas por push.

Com o git 2.7 (janeiro de 2016), um simples empurrão do git será suficiente para empurrar o repositório pai ... e todos os seus submódulos.

Consulte confirmar d34141c , confirmar f5c7cd9 (03 de dezembro de 2015), confirmar f5c7cd9 (03 de dezembro de 2015) e confirmar b33a15b (17 de novembro de 2015) por Mike Crowe ( mikecrowe) .
^{(Mesclado por Junio ​​C Hamano - gitster- na confirmação 5d35d72 , 21 de dezembro de 2015)}

push: adicionar recurseSubmodulesopção de configuração

O --recurse-submodulesparâmetro da linha de comando existe há algum tempo, mas não possui um arquivo de configuração equivalente.

Seguindo o estilo do parâmetro correspondente para git fetch, vamos inventar push.recurseSubmodulespara fornecer um padrão para este parâmetro.
Isso também requer a adição de --recurse-submodules=nopara permitir que a configuração seja substituída na linha de comandos quando necessário.

A maneira mais direta de implementar isso parece ser pushusar código de submodule-configmaneira semelhante a fetch.

O git configdocumento agora inclui :

push.recurseSubmodules:

Verifique se todos os commits do submódulo usados ​​pelas revisões a serem enviadas estão disponíveis em uma ramificação de rastreamento remoto.

• Se o valor for ' check', o Git verificará se todos os commit do submódulo que foram alterados nas revisões a serem enviadas estão disponíveis em pelo menos um controle remoto do submódulo. Se algum commit estiver ausente, o push será abortado e sairá com status diferente de zero.
• Se o valor for ' on-demand', todos os submódulos que foram alterados nas revisões a serem enviadas serão enviados. Se a demanda não puder enviar todas as revisões necessárias, ela também será abortada e sairá com status diferente de zero. -
• Se o valor for ' no', o comportamento padrão de ignorar submódulos ao pressionar é mantido.

Você pode substituir essa configuração no momento do envio, especificando ' --recurse-submodules=check|on-demand|no'.

Assim:

git config push.recurseSubmodules on-demand
git push

Git 2.12 (primeiro trimestre de 2017)

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

Consulte commit 0301c82 , commit 1aa7365 (17 de novembro de 2016) por Brandon Williams ( mbrandonw) .
^{(Mesclado por Junio ​​C Hamano - gitster- na confirmação 12cf113 , 16 de dezembro de 2016)}

push run with --dry-runna verdade (Git 2.11 dez. 2016 e inferior / anterior) executa uma execução a seco quando o push está configurado para enviar submódulos sob demanda.
Em vez disso, todos os submódulos que precisam ser enviados são enviados para seus controles remotos, enquanto as atualizações para o superprojeto são executadas como uma execução a seco.
Este é um erro e não o comportamento pretendido de uma execução a seco.

Ensine pusha respeitar a --dry-runopção quando configurado para enviar recursivamente os submódulos 'sob demanda'.
Isso é feito passando o --dry-runsinalizador para o processo filho, que executa um push para um submódulo ao executar uma execução a seco.

E ainda no Git 2.12, você agora " --recurse-submodules=only" tem a opção de empurrar submódulos para fora sem empurrar o superprojeto de nível superior .

Consulte commit 225e8bf , commit 6c656c3 , commit 14c01bd (19 de dezembro de 2016) por Brandon Williams ( mbrandonw) .
^{(Mesclado por Junio ​​C Hamano - gitster- na confirmação 792e22e , 31 de janeiro de 2017)}