¿Cómo obtengo `git clone –recursive` para recrear los controles remotos y las ramificaciones de los submodules?

Tengo un proyecto con un puñado de submodules. Muchos de ellos se clonan desde un tenedor GitHub al que he agregado una twig para mis modificaciones personalizadas. Una configuration típica es así:

En la carpeta local: MyProject1 / Frameworks / SomeAmazingRepo /

$ git branch -vva *my-fork 123456 [my-fork/my-fork] Latest commit msg from fork master abcdef [origin/master] Latest commit msg from original repo remotes/my-fork/my-fork 123456 [my-fork/my-fork] Latest commit msg from fork remotes/my-fork/master abcdef [origin/master] Latest commit msg from original repo remotes/origin/HEAD -> origin/master remotes/origin/master abcdef [origin/master] Latest commit msg from original repo $ git remote -v my-fork git@github.com:MyUser/SomeAmazingRepo.git (fetch) my-fork git@github.com:MyUser/SomeAmazingRepo.git (push) origin git://github.com/OriginalOwner/SomeAmazingRepo.git (fetch) origin git://github.com/OriginalOwner/SomeAmazingRepo.git (push) 

Me git clone --recursive mi proyecto para comenzar un nuevo proyecto de spin-off y cuando comienza a recurse, escupe un error que dice que no puede encontrar los commits almacenados para estos repositorys. Tras la inspección, parece que los controles remotos no se han agregado y la twig se deja (vacía) en el maestro …

En la carpeta local: MyProject2 / Frameworks / SomeAmazingRepo /

 $ git branch -vva *master abcdef [origin/master] Latest commit msg from original repo remotes/origin/HEAD -> origin/master remotes/origin/master abcdef [origin/master] Latest commit msg from original repo $ git remote -v origin git://github.com/OriginalOwner/SomeAmazingRepo.git (fetch) origin git://github.com/OriginalOwner/SomeAmazingRepo.git (push) 

El único remedio es ir y agregar los controles remotos manualmente a todos los repos (muy tedioso).

Existe un problema similar en los casos en que hay dos twigs de rastreo como las anteriores pero solo un control remoto (origen => mi bifurcación Github). En estos casos, encuentra la confirmación y la verifica, pero no recrea la twig de seguimiento, lo que deja un compromiso "colgando" … ¡muy aterrador ya que no lo advierte!

¿Cómo puedo clonar mi proyecto para que cree de manera confiable los controles remotos y las ramificaciones de los submodules?

git clone --recursive es equivalente a git submodule update --init --recursive .

Y una actualización del submodule de git solo registrará el SHA1 registrado (registrado en el repository principal):

Actualice los submodules registrados, es decir, clone los submodules que faltan y ejecute la confirmación especificada en el índice del repository contenedor.
Esto hará que los submodules HEAD sean separados .

2012: Entonces, no encontrar una twig activa en un submodule es la norma.
Un git submodule foreach 'git checkout master' puede al less establecer la twig principal (si está seguro de que se suponía que todos los SHA1 grabados eran parte de una twig 'master' para cada submodule).


2013-2014: puede configurar su file .gitmodules para especificar una bifurcación para realizar el pago en su submodule .
Consulte " ¿Cómo actualizo mis submodules de git desde twigs específicas? "

 cd /path/to/your/parent/repo git config -f .gitmodules submodule.<path>.branch <branch> 

Cualquier control remoto que agregue localmente en un submodule, como my-fork , no se registrará en el repository principal.
Por lo tanto, cuando vuelva a clonar ese repository principal, se inicializarán y actualizarán los submodules tal como se registraron en el file .gitmodules (puede cambiar esa dirección , pero solo uno está asociado con cada submodule).
Si tiene otra dirección remota para asociar a cada submodule, necesita una secuencia de commands para automatizar el process.

Como se explica en " Verdadera naturaleza del submodule ", un submodule está allí principalmente para registrar / acceder a un punto fijo en el historial.
Puede desarrollar directamente dentro de un submodule, pero necesita ir allí y hacer la twig correcta y / o agregar los controles remotos correctos.

escupe un error que dice que no puede encontrar los commits almacenados para estos repositorys.

Cada vez que realiza una confirmación en un submodule, necesita:

  • empújelo al control remoto asociado (es decir, el registrado en los .gitmodules del repository principal)
  • regrese al repository principal y comprometa a dicho padre.

Pero:

Si presionó ' my-fork ' mientras el repository remoto asociado de ese submodule no era ' my-fork ' … entonces el próximo clon no podrá verificar que el submodule se haya comprometido.


Actualización de agosto de 2014 (Git 2.1)

Ver commit 9393ae7 por Matthew Chen ( charlesmchen ) :

submodule: document " sync --recursive "

El command " git submodule sync " admite el indicador --recursive , pero la documentation no menciona esto.
Esa bandera es útil, por ejemplo, cuando se cambia un control remoto en un submodule de un submodule.