Divida el repository grande en múltiples repos más pequeños al momento del envío

Tengo un proyecto alojado en github con la siguiente estructura

github.com/example/allpackages

 . ├── .git └── packages ├── example-1 ├── example-2 └── example-3 

En cada envío a github, me gustaría que los contenidos de cada package se envíen a un repository que corresponde al nombre del repository, por ejemplo:

github.com/example/example1

 . ├── .git └── example1 

github.com/example/example2

 . ├── .git └── example2 

etc.

¿Alguien tiene alguna idea sobre cómo automatizar esto? Alguien mencionó el uso de Travis-CI para esta tarea, pero no pude encontrar ningún detalle sobre cómo podría funcionar.

Mi solución ideal:

  • Sería completo automatizado, lo que significa que la actualización no se desencadenaría por la computadora que empuja, sino más bien por github o por un service externo.
  • Migre el historial de "todos los packages" a los subrepos correspondientes en la actualización

Cualquier orientación sobre dónde comenzar a investigar sería muy apreciada. ¡Gracias por adelantado!

Editar:

@VonC sugirió usar submodules y hacer commits usando git submodule foreach --recursive

Pros:

  • Seco: el código de cada submodule vive en un solo lugar.
  • Capaz de seguir los cambios a los submodules en el padre.
  • Usar git submodule foreach --recursive usando un alias permite una única confirmación a múltiples submodules

Contras:

  • Ver los cambios realizados a los submodules no está claro inmediatamente. Uno debe cavar en el submodule para ver qué cambios se han realizado.
  • Usar git submodule foreach --recursive es engorroso y no tan elegante como una confirmación normal.

Para este caso de uso particular. Los repos de "packages", por ejemplo, github.com/example/example1 , solo se leerán en un sentido. No los presionaré directamente. Solo recibirán actualizaciones cuando se actualicen todos los allpackages . La única razón por la que deben crearse es porque el administrador de packages que los utiliza requiere repos separados para cada package.

Si declara todas sus carpetas exampleX como repository git, y las convierte en submodules de los repos repos allpackages , entonces:

  • cada repository exampleX puede tener su propio repository upstream en GitHub

  • ( desde git 1.7.11 ), puede presionar everyhting a sus respectivos repositorys

     cd allpackages git push --recurse-submodules=on-demand 

Un command, y todo está empujado.

Github no ejecutará los ganchos de repo. La configuration de un repository proxy de github con un gancho post-actualización que adapta el seguimiento automático en esta respuesta y luego reenvía los empujones, a medida que lo leo, satisface los requisitos establecidos.

Dicho eso, sin embargo, estoy con VonC. Si no va con submodules va a estar atascado con algo así, y en realidad, no es más que un submodule frágil, tullido y sigiloso que solo funciona para ese repository, y que se romperá tan pronto como alguien lo presione. en cualquier lugar less a ese proxy. Puede ser muy conveniente para su propio trabajo, en un repository privado, y hay forms de eliminar la fragilidad un paso más adelante, pero para una disciplina compartida, no es lo suficientemente robusto.

Para el trabajo compartido apostaría a que tarde o temprano terminarás cambiando a submodules y descubrirás que no son muy misteriosos. Así que ignóralo y acepta la respuesta de VonC 🙂

Todavía prefiero el enfoque limpio de "submodule" que recomendé antes .

Pero otra forma más tediosa de enviar una carpeta de un repos a un repository upstream independiente sería utilizar la técnica de repos repo .

 cd myrepos git clone https://github.com/example/example1 git clone https://github.com/example/allpackages cd allpackages/packages/example-1 git --git-dir=../../../example1/.git add . git --git-dir=../../../example1/.git commit -m "commit for example1" git --git-dir=../../../example1/.git push 

Eso consideraría, para el allpackages/packages/example-1 repo de GitHub, el tree de trabajo de allpackages/packages/example-1 : --git-dir hace que Git crea que allpackages/packages/example-1 es un repository de git (nested) propio, con un ' origin ' remoto que hace reference a GitHub.

Pero : eso significaría 3 commands push diferentes, a less que ajuste esos commands en un script y llame a esos scripts a través de un git alias :

 git config alias.pushall '!sh pushall.sh'