git - ¿Cómo usar los submódulos públicamente, pero los enlaces simbólicos a un solo clon localmente?

symlink git-submodules

Question

Estoy teniendo mi primera experiencia Git Submodule.

Tengo algunos proyectos que dependen del mismo subproyecto. Mantengo estos proyectos sincronizados, así que estoy usando la función "rama de submódulo" (por ejemplo, git submodule add -b master [URL] ).

Si bien me gustaría que los repositorios públicos de GitHub transmitieran la relación de submódulo, en mi propio flujo de trabajo realmente me gustaría tener un clon del código compartido en mi disco. Pensé que solo podía configurar los submódulos y luego hacer un switcheroo con un enlace simbólico. Pero cuando lo hago, me sale esto:

On branch master
Changes not staged for commit:
 (use "git add <file>..." to update what will be committed)
 (use "git checkout -- <file>..." to discard changes in working directory)

    typechange: draem

Así que Git aparentemente ve el hecho de que es un enlace simbólico, en lugar de seguir hasta el directorio.

¿Hay algún flujo de trabajo en el que parezca que estoy trabajando con submódulos, pero en realidad solo tengo un clon en mi sistema de archivos local?

Answer 1

Así que Git aparentemente ve el hecho de que es un enlace simbólico, en lugar de seguir hasta el directorio.

Sí, Git vería tal cambio, porque ese submódulo se declara en el repositorio principal como una entrada especial en el índice .

Hacer un enlace simbólico reemplazaría esa entrada especial por un archivo de otro tipo.

Lo que podrías hacer es intentar jugar con GIT_WORK_TREE (como en " Incluir submódulos en la comprobación de git para GIT_WORK_TREE en gancho ").

Pero una solución más simple sería:

• mantén tu submódulo justo donde están.
• agregue otro clon de ese repositorio de submódulo donde lo desee ( /path/to/sub ).
• detecte cualquier cambio de la carpeta de submódulos original con git --work-tree=/path/to/sub status desde su carpeta de submódulos duplicados en sus repositorios principales.

Answer 2

Personalmente, no recomendaría que los submódulos de diferentes proyectos apunten al mismo código. Si el código del submódulo es realmente grande, podría ser un argumento, pero en la mayoría de las situaciones no lo haría.

Esto también puede ser bueno porque puede desarrollarse en el submódulo de uno de sus proyectos y no afectar a los otros.

Answer 3

Puedes enlazar el otro directorio del submódulo

sudo mount --bind /path/to/main/repo relative/path/to/submodule

No puedo encontrar mucha información sobre este método, pero lo vi en this pregunta similar.

Answer 4

(Aprecie los otros consejos, pero responda con lo que he decidido hacer, porque es más fácil).

Ponga clones de los submódulos que planea compartir en sus propios directorios.

Luego, configure las cosas como quiera en los proyectos de uso, cada uno con su propio clon del submódulo (s) que planea compartir. Una vez que los proyectos estén configurados de manera que los nuevos usuarios obtengan los submódulos normalmente, reemplace los directorios de submódulos con enlaces simbólicos compartidos a su única instancia local en la que realiza las ediciones y agréguelos a .gitignore.

(En lugar de simplemente eliminar los directorios basados ​​en submódulos, es posible que desee cambiarles el nombre a un lugar. Luego, puede moverlos de nuevo a su lugar y tirarlos si es necesario).

Así que el estilo de trabajo es simplemente no enviar nunca el submódulo / cambio de tipo. Mientras esté dispuesto a seguir siempre la rama maestra, las personas que clonen el proyecto seguirán obteniendo lo correcto. Mientras tanto, puede trabajar con el repositorio único en su disco.

Para proyectos en una etapa más avanzada, @VonC probablemente tenga la respuesta correcta ... no mentirle a Git, revisar los submódulos en los estados apropiados y usar los activadores para administrar las actualizaciones.