alternativa del submódulo de Git?

Question

Tengo un par de árboles que funcionan con algunas dependencias. Que yo sepa, submódulo git haría cumplir lo siguiente:

• tienen una copia de cada árbol de trabajo (esclavo) en un subdirectorio de cada árbol de trabajo de usarlo (maestro)
• el repositorio maestro duplica toda la información de esclavos

No me importa que los repos se hagan más grandes, pero tener las copias es bastante inaceptable para mí. Me obligaría a reorganizar todos los proyectos, para que la copia se vincule. Además, la edición de un archivo incorrecto podría ocurrir fácilmente y generar confusión.

Tengo otra idea:

• Cada maestro almacena una lista de todos sus esclavos.
• No se requiere otra información en el máster.
• Con cada confirmación en el maestro, se crea un "snapshot-commit" en el esclavo.
• El "snapshot-commit" es una instantánea del estado actual del árbol de trabajo, ignora el estado actual del índice (ya estoy usando "snapshot-commits" antes de descartar algunos cambios sin compromiso).
• Los "snapshot-commits" se recopilan en una rama cuyo nombre se deriva del nombre del maestro. El mensaje de confirmación contiene el hash de la confirmación maestra. (En mi humilde opinión, esto es mejor que la inundación de miles de etiquetas.)
• Un pago y envío funciona como de costumbre, a menos que se requiera la recursión en esclavos.

El único problema que puedo ver son los siguientes:

• Las confirmaciones de los esclavos se acumulan, y nunca se eliminan incluso cuando el maestro se compromete ya no existe.
• Las confirmaciones en el maestro no son autosuficientes, podría eliminar una confirmación referida en el maestro. Pero no veo ninguna posibilidad de que pueda suceder por accidente, así que puedo vivir con eso.
• No me puedo imaginar cómo otros comandos de git podrían soportar esto. Pero de nuevo, puedo vivir con eso.

Pregunto si alguien ya lo implementó (o si es una mala idea).

Answer 1

No estoy seguro de que lo sigo, ya que un repositorio padre (su "maestro") solo almacena una referencia al SHA1 ajustado de un submódulo (el sub-repo verificado en el repositorio principal).
El tamaño del repositorio principal no se ve afectado en absoluto.

subtree merge strategy (better managed though git subtree) aumentaría el tamaño del repositorio primario, pero eso (combinación de subárbol) no es de lo que está hablando.

La otra alternativa al submódulo sería git-slave (gits), que es un poco como si quisiera implementar.

Answer 2

Creo que esta es una mala idea porque es extraña y te sacará de la ruta admitida por muchas cosas.

Primero, una aclaración: cuando se utilizan submódulos, el repositorio 'maestro' (referenciado) no se hace apreciablemente más grande. Almacena solo una referencia de repositorio (URL, probablemente) y una ID de confirmación. Pero ese no parece ser el punto de fricción aquí.

Cuando se trata de un problema como este hay tres caminos básicamente 3 se puede bajar:

1. Poner todo en un único repositorio. ¿Te has convencido a ti mismo 10 veces de que realmente necesitas separar las cosas? Recuerde que puede comenzar en un repositorio y dividir las cosas más tarde. También recuerde que las fusiones de git realmente funcionan, por lo que la disputa entre desarrolladores no es un gran problema.

2. Utilice algún sistema de gestión de paquetes externo. Git NO es, y no pretende ser, un administrador de paquetes. Las probabilidades son buenas de que la plataforma que está utilizando tenga un administrador de paquetes que admita situaciones de dependencia más complejas. Maven, rubygems, npm, nuget ... hay muchos de ellos.

3. Utilice los submódulos 'montados' en los subdirectorios.

Básicamente, los submódulos deberían ser su última opción al tratar con su propio código. Son geniales para tratar con bibliotecas de terceros, pero terminan siendo un dolor real para tu propio código. Añada a eso la solución complicada que está proponiendo, y simplemente no será muy divertido trabajar con ella.