Crear repository de Git con ruta de dominio inverso sin colisión

En ActionScript (y en muchos otros lenguajes, sospecho) es común el espacio de nombres de sus bibliotecas con una ruta única de dominio inverso, por ejemplo: com.zeitguys.mylibrary , que se traduce en una estructura de directory físico de (lib)/com/zeitguys/mylibrary .

Para comodidad del usuario final de esta biblioteca, desea que se desempackage y cree la ruta completa, por lo que la raíz del repository tiene el directory com como único elemento secundario (¿ o debería? ).

Supongamos que está trabajando en dos bibliotecas diferentes, que deben poder coexistir, pero que realmente deberían tener repositorys Git separados, ya que no están relacionados (aparte del hecho de que fueron creados por el mismo autor, de ahí el mismo reverso). raíz del dominio). por ejemplo: com.zeitguys.lib1 y com.zeitguys.lib2 .

Ahora suponga además que desea include AMBAS bibliotecas en un proyecto y mantenerlas vinculadas a sus respectivos repositorys de Git. ¿Cómo puede ser esto? Ambos repositorys comparten una estructura de directory común para algunos niveles antes de la bifurcación.

Mi pregunta es sobre cómo estructurar el repository remoto, en lugar de cómo comprar un subdirectory en mi copy de trabajo. Mi perspectiva es pensar en el consumidor del repository y no forzarlos a recrear manualmente la estructura com.zeitguys.mylibrary para usar correctamente el código fuente.

Para comodidad del usuario final de esta biblioteca, desea que se desempackage y cree la ruta completa, por lo que la raíz del repository tiene el directory com como único hijo

  1. Puede ser una tarea de su herramienta de deployment de packages , no de VCS per se (me puedo imaginar a Git-repo en Somedir , que está empaquetado para desplegar en file con path /com/zeitguys/lib1 en él)
  2. Puede ser una tarea de solo herramienta de implementación , que verificará la presencia y creará (si es necesario) todos los padres intermedios y la carpeta de su lib en el lado del cliente
  3. Como último recurso, puede utilizar los subtreees | subtreees de Git, con SuperRepo ("contenedor" vacío) en /com/zeitguys/ (o solo /com , si usa espacios de nombres totalmente diferentes), que tienen repositorys independientes en /com/zeitguys/* como submodules

Creo que mi enfoque general fue defectuoso desde el principio. Es decir, el concepto de que mi repository de gitHub se convertiría en el directory que está incluido en la ruta de la biblioteca del usuario final.

El hecho es que ese no será el caso. El repository es solo el repository. Dentro de ese repository va a haber un directory src y ese directory contendrá com/zeitguys/lib1 . Por lo tanto, el segundo repository también tendría su propio directory src con sus com/zeitguys/lib2 .

Esta idea (si es que se puede llamar así) es bastante liberadora. Permite que el repository contenga un montón de otras cosas que tiene poco que ver con el código src que el usuario final includeía en su classpath / proyecto, por ejemplo, files README.md, scripts de compilation, una carpeta de examples , suite de testings, etc. .