Varios repositorys con un solo submodule

He buscado por un time y no encontré respuesta (tal vez no sé qué search).

Tenemos una biblioteca principal que es un repository en sí mismo (llamémosla Lib) que contiene la mayoría de nuestros modules y submodules. Digamos también que tiene un tamaño de 2 GB …

Ahora tenemos muchos proyectos como: ProjA, ProjB, ProjC, cada uno usa el Lib como submodule.

ProjA

  • Lib (branch: master, commit #: 1)

ProjB

  • Lib (branch: other, commit #: 2)

ProjA

  • Lib (branch: master, commit #: 4)

Así que, aunque soy capaz de mantener cada reference de proyecto para corregir la versión de la biblioteca (también conocido como submodule). Ahora tengo 3 * 2GB = 6GB de EL MISMO submodule.

¿Hay alguna manera de hacer reference a un solo submodule mientras se mantienen los files correctos / versiones referencedas?

P.ej.

ProjA

  • Lib / base_lib.h (v1.0)

  • Lib / file_only_in_this_commit

ProjB

  • Lib / base_lib.h (v1.0)

ProjC

  • Lib / base_lib.h (v1.1)

¡Gracias!

Puedes usar git worktree (disponible desde git 2.5) para crear worktrees adicionales para el submodule Lib, en las ubicaciones dentro de ProjA, ProjB, etc.

Debido a que git worktree hace un esfuerzo hacer varios worktrees con el mismo nombre (todos se llaman "Lib"), acabo de crear un script, compartir_submodules para evitar las dificultades y crear el worktree adicional en lugar de un submodule, configurarlo en el el submodule derecho se compromete y lo hace recursivamente para todos los submodules dentro del module compartido.

Debería funcionar tan bien como si el submodule fuera creado por la git submodule update --init --recursive , excepto que todas las copys hacen reference a los objects de un module.

Si está haciendo la transición eliminando el submodule, hay files de submodules parásitos en su .git y creé find_stray_submodules.py para limpiarlos.

Bueno, internamente todo el submodule es bastante simple, así que puedes dominarlo a tu gusto.

Dentro de cada uno de sus Proj<N>/.git/modules/ hay una carpeta correspondiente al submodule Lib con el repository vacío clonado de la reference remota especificada en Proj<N> /.gitmodules en Lib.url . Esos repositorys desnudos son los puntos de optimization.

Simplemente puede recrearlos usando enlaces duros cuando sea posible.

1) Cree un clon desnudo de su Lib en una carpeta en el mismo sistema de files que todos sus repositorys Proj:

  git clone --bare url://to/Lib /path/to/Lib.git 

2) Reemplazar el repository de submodule por defecto con el repository, haciendo reference al repository vacío de p.1:

 mv ProjA/.git/modules/Lib ProjA/.git/modules/Lib.old // preserve it for a while git clone --bare --local url://to/Lib \ --reference /path/to/Lib.git ProjA/.git/modules/Lib 

3) Restaure la configuration desde el repository conservado en ProjA/.git/modules/Lib :

 cp ProjA/.git/modules/Lib.old/config ProjA/.git/modules/Lib/config 

Ahora puede verificar si todo funciona en ProjA y eliminar ProjA/.git/modules/Lib.old y demás. En este caso, todos los repos utilizarán los mismos objects de file.

En git un estado particular de un submodule es referencedo por un SHA1 preciso. A less que realice algunas operaciones "malvadas" en su repository principal de Lib (por ejemplo, git filter-branch u otras operaciones que pueden llevar a la eliminación de un commit), todos los commits apropiados en Lib se mantendrán para siempre. Su Proj<N> comtesting las confirmaciones particulares de forma completamente independiente, por lo que no debe molestarse en que un estado de Lib en ProjA pueda interferir con otro estado de Lib en ProjB .