El submodule Git tiene una reference incorrecta a su repository remoto

Tengo dos submodules en mi repository principal, ambos vinculados a otros dos repositorys remotos.

  • Cuando entro al 1er submodule recibo un post "CABEZA separada en xxxxxxxx" – lo cual está bien, porque el repository remoto y el submodule tienen el mismo ID (los 32 dígitos).
  • Cuando entro al segundo submodule recibo un post "CABEZA separada de yyyyyyyy", lo cual no está bien, porque el repository remoto y el submodule no tienen la misma ID (los 32 dígitos). Por lo tanto, el segundo submodule tiene una ID diferente a la del repository al que está vinculado.

Creo que de alguna manera logré poner mi segundo submodule en alguna otra twig o algo así.
Para abreviar, ya no puedo clonar el representante principal ( git clone --recursive-submodules ) porque el segundo submodule tiene una identificación incorrecta y no puede vincularse a su representante remoto.
Estoy recibiendo " error: no ref to the remote rep ".

¿Alguien me puede ayudar?
¿Cómo puedo cambiar la ID de un submodule?
¿O necesito recuperar mi segundo submodule en la twig principal?

¿Cómo puedo cambiar la ID de un submodule?

En su caso, no puede clonar el repository de submodules, porque su gitlink , ( input especial en el índice del repository principal ) hace reference a un SHA1 que no fue enviado al repository remoto de dicho submodule.

Como no tiene el contenido de la carpeta del submodule (no se puede desproteger), no puede simplemente agregar, presionar y comprometer desde dicho submodule.

Para completar el clon, es mejor cambiar el gitlink SHA1 asociado a su versión anterior:

 git checkout $(git log -1 --format=format:%H yoursubmodule) -- yoursubmodule 

Reemplace yoursubmodule por el nombre de la carpeta que representa su submodule, sin barra diagonal (ya que es una input en el índice, no en una carpeta)

Entonces, una git submodule update --init debería ser suficiente para inicializar el contenido de ese submodule.

Finalmente, vea " Submodules de Git: especifique una twig / label ", y asocie su submodule a una bifurcación:

 git config -f .gitmodules submodule.<path>.branch <branch> 

De esa forma, la próxima vez, una submodule update --remote git submodule update --remote será suficiente para actualizar su submodule al último SHA1 remoto de esa twig.

TL; DR: lo que obtuviste es, creo, el caso que menciono a continuación en el que no has empujado la confirmación del submodule . Así que ahora, cuando el superproyecto va a get el compromiso específico del submodule que el superproyecto ha clonado, (el superproyecto Git) no puede encontrarlo (el compromiso deseado en el submodule).

Fondo

Los submodules son un dolor porque existe una enorme tensión entre el hecho de que cada submodule en sí es un repository de Git y el hecho de que cada "superproyecto" (que controla un submodule) insiste en que sabe qué compromiso debe usar el submodule.

Todo esto funciona bien cuando todos sus submodules son bibliotecas externas que otra persona mantiene. Usted escribe un código que necesita las bibliotecas A, B y C. Lo testing con "commit 1234567 " desde A, "commit 8888888 " desde B, y "commit fedcba9 " desde C, y todo funciona … para que decrete que esta versión del código siempre y para siempre usará esos tres commits de esos tres submodules.

Usted hace esto simplemente haciendo una confirmación en el superproyecto . Cada commit registra, para todo el time, exactamente en qué commits deben estar los submodules.

Luego, cada vez que revisa el superproyecto, le dice a su superproyecto Git que se entrometa en cada sub-repository y separe su HEAD. Es por eso que ves "desapegado" o "desapegado". La parte "a" o "a partir de" es totalmente irrelevante en este punto: ¡no le prestes atención! Esto es para su información cuando está trabajando en esas bibliotecas, y porque en realidad está trabajando en el superproyecto, su superproyecto Git supone que no está trabajando en ellas.

Pero hay un problema: ¿y si quieres trabajar en ellos? Tu superproyecto Git te grita: ¡ No, no, no puedes tocarlos! Yo los controlo! 🙂 Bueno, no es tan malo, pero … es malo.

Para trabajar en un repository, generalmente quiere estar en una sucursal. Así que debes ingresar al submodule y deshacer lo que hizo tu superproyecto Git, echando un vistazo a alguna twig en particular. Ahora puede trabajar en el submodule de la manera normal.

Pero esto altera tu superproyecto Git. Además, no puedes probarlo realmente hasta que tengas todo alineado nuevamente. Debe ingresar todos los submodules, retírelos al modo "branch-y", trabaje en ellos, tal vez los pruebe individualmente, y tal vez incluso realice commits. Ahora puedes volver a tu superproyecto … pero todavía no puedes hacer commits porque aún restringn los antiguos hash de HEAD.

La única forma de volver a alinear todo es realizar las confirmaciones en los submodules. Ahora cada submodule tiene una nueva ID de hash, que cada Git de submodule asignó cuando realizó las confirmaciones allí. Ahora puede upload de nuevo a su superproyecto y decirle a Git: "Estoy listo para comprometerme, pero antes de hacerlo, aquí están sus nuevas ID de hash". Esto se hace git add cada submodule nuevamente, lo que hace que su superproyecto Git vaya y lea los valores hash del submodule y los ponga en el índice de su superproyecto. Ahora puedes git commit en el superproyecto, que de forma permanente, para siempre, registra la nueva confirmación como el uso de los nuevos hash para cada uno de los diversos submodules.

Tenga en count que si ahora empuja el superproyecto, todos los demás tienen un problema: los nuevos commits hechos en los submodules están en los repositorys de submodules, pero esos commits aún no han sido reubicados donde sea que vayan. Cualquiera que obtenga su nueva confirmación de superproyecto recibe una confirmación que dice "el submodule A debe usar cometer de feedcab ", pero no pueden get el feedcab confirmación hasta que usted empuje eso también. Entonces debes empujar todos los submodules primero, y solo luego empujar el superproyecto.

Esto funciona, pero observe cuán quebradizo y frágil es el process. Los submodules de Git han mejorado con el time, ya que ahora puedes decirle al superproyecto que controla Git (recursivamente) que descienda a cada submodule Git y ponerlo en una twig (cuyo nombre de twig se registra en el superproyecto). Eso soluciona el primer problema.

Sin embargo, si no eres quien controla el repository remoto del submodule, obtienes un set diferente de problemas. El command de git submodule update ha desarrollado una gran cantidad de opciones adicionales para tratar de acomodar estos casos también. El command git submodule foreach permite ejecutar cualquier cosa (como sus propios scripts) en cada submodule, lo que le otorga un control total, a expensas de hacer que escriba, bueno, tenga el control completo. Pero la situación con los submodules sigue siendo bastante desorderada, y muchas organizaciones tratan de evitarlos (lo haría y lo haré yo mismo).