¿Cuál es la mejor práctica con git para implementaciones en múltiples idiomas?

Question

Así que tengo algunos repositorios git privados que son implementaciones de lenguaje diferente (Python, Java, etc.) de un algoritmo. Cada implementación es funcionalmente idéntica, realizando los mismos pasos y dando el mismo resultado. Actualmente, estos son repositorios separados, pero me preguntaba si no debería unificarlas en una sola cesión temporal, con los directorios que indica el lenguaje, como:

master 
    - java 
    - python 
    - ruby 

que podría utilizar un git-repo combinar comandos para preservar la historia , entonces eso no es un problema. Tenía curiosidad sobre la mejor práctica con respecto a esto.

Answer 1

Tuve esta misma pregunta con Mercurial, y un algoritmo (COBS) que quería implementar en C y Python.

Eventualmente decidí dividirlo en repositorios separados (aunque la implementación de Python incluía una extensión C que tenía un código similar a la implementación C simple). Mi razonamiento se redujo a:

• Quería tener la numeración de versión independiente de las implementaciones y versiones independientes.
  • git describe es una buena característica para identificar una versión basada en la última etiqueta anotada. Con solo una implementación en el repositorio, el uso de git describe es simple. Pero si hay diferentes implementaciones con números de versión separados en el repositorio único, entonces el uso de git describe se vuelve más complicado, y es necesario utilizar la opción --match para limitar las etiquetas con un prefijo dado. p.ej. git describe --match "python*" módulos de Python
• La forma en que se organizan normalmente (Python module packaging best-practices), que tenía más sentido para mí para mantener la implementación de Python independiente y autónomo.
• En igualdad de condiciones, tiendo a favorecer una modularidad más fina.

Answer 2

Es una decisión difícil. Probablemente, lo que es "mejor" simplemente se reducirá a las preferencias personales y/o las características específicas de las circunstancias.

Por un lado, cada directorio no está "relacionado" técnicamente con ningún otro. Si bien implementan el mismo algoritmo, ninguno depende de ninguno de los otros (por lo tanto, desde el punto de vista del código fuente puro, no están relacionados). Por lo general, las cosas no relacionadas se dejan mejor en repositorios separados (por razones identificadas en la respuesta de Craig McQueen).

Sin embargo, debido a que do implementan el mismo algoritmo, puede encontrar que si necesita cambiar el algoritmo, deberá realizar cambios muy similares en todos los directorios. En tal caso, podría tener sentido para hacer todos los cambios como una única confirmación. Digamos que usted decide que el algoritmo debe ser compatible con "dinglehoppers virtuales". Agregaría ese soporte a cada directorio y haría una única confirmación cuyo mensaje es "Agregar soporte para dinglehoppers virtuales". Esto es bueno porque si más adelante decide que la adición de la compatibilidad con dinglehopper virtual era malo, ahora puede revertir solo una confirmación. La alternativa es hacer tres confirmaciones separadas para tres repositorios separados y luego revertir tres compromisos separados de tres repositorios separados.

Una vez más, es una decisión difícil. No creo que haya una regla bien definida y duradera.