submodulos - ¿Por qué `git checkout` no hace automáticamente` git submodule update--recursive`?
gitlab submodules (2)
Básicamente, quieres que git haga todas las operaciones de forma recursiva y automática para todos los submódulos. Lo que probablemente sea trivial en un modelo centralizado de cliente-servidor como svn.
Pero se distribuye git. Su submódulo puede provenir de una URL totalmente diferente, con un protocolo totalmente diferente. Lo más probable es que no tengas acceso directo al repositorio de origin del submódulo, mientras que lo haces para el repositorio principal.
Así que no puede haber un empuje recursivo.
Por lo tanto, los diseñadores probablemente decidieron evitar la recursión automática de submódulos en todas partes. Lo cual es consistente, pero una gran cantidad de dolor.
Tanto es así, que en un determinado proyecto los abandonamos por completo y, en su lugar, usamos las combinaciones de subárbol.
ACTUALIZACIÓN de mi último comentario, porque es importante:
Uno podría notar en mi respuesta que no sé por qué no hay un proceso de pago recursivo. No soy un desarrollador de Git. Solo insinué que hay operaciones, .eg push, que no pueden ser recursivas. Así que los desarrolladores podrían haber decidido evitar la recursión en submódulos por completo para mantener la coherencia . ¿Pero quién sabe? En realidad es un misterio. ¿Quién sabe qué hay en la cabeza de los desarrolladores de Git? ¡Me acabo de dar cuenta ahora que mi respuesta está basada en la OPINIÓN! ¡¡¡Soy un idiota!!! ¡¡¡¡¡¡¡¡¡¡¡Ayuda!!!!!!!!!!!
Alguien por favor ayúdame a entender los submódulos en git. Sé que están teniendo muchos ataques en Internet, pero dado que asumo que los desarrolladores de git son personas inteligentes, hay una razón para el comportamiento actual, y tal vez una forma de solucionar mi problema.
Entonces, tengo un proyecto y algunos submódulos. El proyecto tiene diferentes ramas, como:
- MyApp_version2
- MyApp_version3
- MyApp_version4
- MyApp_liteversion
- MyApp_development
Mis submódulos no se actualizan con tanta frecuencia (tal vez una vez a la semana), por lo que estoy de acuerdo con que no se adjunten al jefe del repositorio de submódulos automáticamente .
Sin embargo, cuando reviso una rama antigua, porque necesito corregir un error en una versión anterior del software, también necesito actualizar los submódulos.
¿Por qué necesito hacer esto?
Espero que git funcione como svn. Cuando cometo mi trabajo en mi repo principal, espero que git piense algo como esto: "Bien, él quiere cometer su trabajo ahora. Puedo ver que los submódulos están actualmente en revisión abc, por lo que en algún momento en el futuro. Vuelta a este compromiso, probablemente quiera los submódulos en la misma revisión de nuevo ".
No puedo ver un solo caso en el que quiera que los submódulos permanezcan en la revisión actual mientras retrocede 3 años en su repositorio principal. Sin embargo, debe haber una razón para esta implementación, ¿verdad?
Realmente me gustaría escuchar si alguno de ustedes conoce los pensamientos detrás de esto, pero en cualquier caso realmente me gustaría una solución. ¿Hay alguna manera de decirle a git: "Quiero realizar este trabajo con estos submódulos. Si en algún momento vuelvo a este estado, quiero que los submódulos también se revisen en la versión correcta".
Ejemplo para aclarar
Mi repositorio principal es una aplicación que necesita usar SSL, y encuentro una biblioteca SSL (libSSL) que agrego como un submódulo.
El 31 de octubre de 2010, creo un commit en mi repositorio principal (2fd4e1) mientras que el submódulo apunta a libSSL versión 3 (c67a2d).
El tiempo pasa, libSSl se actualiza a la versión 34, adapto mi código, lo hago bien.
El 14 de mayo de 2013, creo un nuevo commit (28fced) y un submódulo apunta a la versión más reciente de libSSL (849ee1).
Sin embargo, si reviso 2fd4e1, mi submódulo permanecerá en 849ee1 aunque el compromiso original se creó con c67a2d. Git sabe que hice el compromiso original con c67a2d y no veo cómo es posible que desee un submódulo que no sea con el que se creó el compromiso original.
Parece que lo que quieres hacer se puede lograr desde git v2.13 con la nueva opción --recurse-submodules de git checkout . Desde la página del manual de git-checkout :
- [no-] recuentos-submódulos
El uso de --recurse-submodules actualizará el contenido de todos los submódulos inicializados de acuerdo con el compromiso registrado en el superproyecto. Si las modificaciones locales en un submódulo se sobrescribieran, la verificación fallará a menos que se use -f. Si no se utiliza nada (o --no-recurse-submodules), los árboles de trabajo de los submódulos no se actualizarán.
Vea también este mensaje relevante de git mailing list sobre esa nueva opción .