¿Qué es "vender"?

Vender es una forma de integrar el trabajo de otros en el suyo. Es lo opuesto a 'vincular' contra la biblioteca de terceros. En lugar de tener esa biblioteca como una dependencia, la aplicación usa esta biblioteca como parte del propio código fuente y mantiene ese código 'dentro' de sí mismo.

Normalmente, la venta se realiza mediante herramientas de lenguaje: bundler, cargo, pip, etc. Pero a veces necesita vender algo que no está cubierto por ningún conjunto de herramientas existente, o algo en varios idiomas, que es imposible encontrar la herramienta de lenguaje 'central' para eso.

La solución para esta situación es vender a nivel git. Tiene su propio repositorio git (lo llamo ' repositorio de destino ') y desea incorporar algún otro repositorio (lo llamo ' repositorio de origen ') como directorio en su (repositorio de destino).

Lo que espera de un sistema de ventas bien diseñado (independientemente de lo que sea o no Git):

Visibilidad Desea saber que se envía un código, lo que significa que no fue escrito por committer.
Procedencia Quieres saber de dónde viene. ¿Cuál era el repositorio que alguien había integrado en su repositorio hace dos años? ¿Y qué versión / commit es?
Capacidad de actualización Desea poder actualizar ese código cuando se solucione algún error en el repositorio original (o tenga una nueva característica esperada). Como caso especial para la capacidad de actualización, desea poder eliminar el código vendored (y solo él).
Repetibilidad Vender no debería ser el arte, debería ser el rígido proceso a prueba de errores. El vendedor que ingrese a la barra debe producir el mismo resultado sin importar quién lo haya hecho.
Transportabilidad Una persona que clone su repositorio debería poder continuar tratando con la venta exactamente de la misma manera que usted lo hizo. Eso significa que toda la información relacionada con el proveedor debe permanecer en el git y debe transferirse durante push / pull.
Gobierno Todos los cambios enviados deben permanecer "tal como están" hasta que alguien los actualice. No desea tener actualizaciones inesperadas (de última hora), además, desea mantener las cosas vendidas disponibles, incluso el repositorio de origen ya no está disponible.
Parchabilidad Desea poder modificar el código enviado y aún así poder actualizarlo a una versión más nueva. Preferiblemente, sin conflictos, pero al menos, con una visibilidad clara de dónde habían ocurrido esos conflictos.

Y, dando la naturaleza git de Git, desea que ese sistema sea amigable con las ramas. Si la rama A tiene código vedado en la versión a1 y la rama B en la versión b1, desea cambiar entre ellas cada vez que cambie entre A y B. Además, desea poder cambiar la versión a1 a a2 y la versión b1 a b2 sin preocupaciones sobre versiones en otra rama.

... Y desea poder vender más de un repositorio externo, por lo que la venta no debe ser un evento único por repositorio.

Como puede ver, es una larga lista de requisitos. Analicé las soluciones existentes (otras) antes de llegar a la mejor solución (proveedor git).

Copiar y pegar

Copiar y pegar es una forma tan cruel de vender cualquier cosa que no tengo nada bueno que decir al respecto. Pierdes procedencia, visibilidad, capacidad de actualización. Sin embargo, no pierde la capacidad de transporte, ya que no hay un enlace al antiguo repositorio en primer lugar. No hagas ventas como esa.

Git-in-git

Este es un truco estúpido pero algo funcional. Cree una carpeta vendored_foobar en su repositorio, vaya a vendored_foobar y clone ese foobar. Regrese al nivel superior y confirme todos los cambios que tenga.

Pros: simple de hacer, proporcionar procedencia local, gobernanza y una excelente capacidad de parcheo.

Contras: es frágil, no sobrevive a la inserción (la carpeta anidada .git no está incluida en su repositorio, por lo que para los observadores externos el código entregado es indistinguible del suyo). Así perderá transportabilidad y procedencia a largo plazo.

Submódulos

La idea es que tengas algunas carpetas de tu git administradas en otro git. Es el "algo" más antiguo que Git había proporcionado. Desafortunadamente, es poco amigable con las sucursales y carece de gobernanza sobre el código distribuido. Si el repositorio remoto desaparece, no puede usar sus submódulos.

Y no olvide lo difícil que es clonar este repositorio.

git subtree

Git puede usar la forma 'subárbol' de combinar gits externos como carpetas en el repositorio local de git. Es casi perfecto, excepto por la capacidad de actualización, la repetibilidad, la procedencia y la visibilidad. Salvo que el manual cava en un historial de git, es imposible ver qué parte del repositorio de git se vende y cuál no. Y no tienes idea de dónde vienen esos cambios. Si committer no ha escrito esto, se pierde información. Y si lo tiene, no es repetible ya que pueden ocurrir cambios menores durante el llenado de esa información.

Entonces, ingrese el ganador premiado, vendedor de git.

Vendedor de Git

Git vendor es una increíble extensión para git escrita por Brett Langdon hace unos tres años. Son solo alrededor de 200 líneas en bash, pero está tan bien escrito que no tengo ninguna queja al respecto (tiene todo lo que un buen programa debería tener: páginas de manual, ayuda, finalización de bash, manejo razonable de errores y guardias a prueba de fallas).

Utiliza git subtree y lo extiende con funciones para cubrir los lados sueltos de la venta por git subtree.

Cada punto importante está marcado:

Visilibrio. Simplemente llame a la git vendor list y vea todas las cosas vendidas.
procedencia Muestra el repositorio remoto y permite ver qué commit fue enviado.
actualizabilidad git vendor update , y es compatible con ramas, etiquetas y confirmaciones como una forma de señalar exactamente qué tomar. Y, por supuesto, puede git vendor remove .
repetibilidad No hay operaciones manuales involucradas, por lo que todos obtendrán el mismo resultado en la venta inicial o después de las actualizaciones.
transportabilidad Todos los cambios se almacenan como etiquetas especiales en el historial de git, por lo que son completamente compatibles con push / pull. Y funcionan muy bien con sucursales y pagos arbitrarios de la historia.
Govenrance. Todo el código vedado se almacena dentro de su repositorio.
parchabilidad Es (verá que una fusión clara entra en conflicto con sus cambios), pero es el lado más débil del proveedor de git. Preferiría tener 'cola de parche' (como en debian / pathes para paquetes de deb), pero sin embargo, hay un soporte mínimo para eso.

Tiene una política específica sobre cómo se distribuyen las cosas: si desea clonar https://github.com/serverscom/dibctl , vaya a vendor/github.com/serverscom/dibctl/ . Puede cambiar la parte ' vendor/ ', pero el resto es una política difícil. Sin embargo, los enlaces simbólicos pueden facilitarlo.

Hay algunos errores menores allí: no puede usarlo en repositorios vacíos, no puede usar gits locales como fuentes, no puede ver ayuda hasta que esté en el repositorio de git. Ninguno de ellos causa problemas durante el trabajo normal con repos reales.

Conclusión

git-vendor es una herramienta perfecta para vender un repositorio de git en otro. Proporciona toda la funcionalidad requerida para las mejores prácticas de venta: mantener la procedencia, proporcionar visibilidad y capacidad de actualización.

Cómo vender un git a otro git