git deps
1.0.0
git-deps es una herramienta para realizar un análisis automático de dependencias entre los compromisos en un repositorio de GIT. Aquí hay una demostración de screencast:
He blogueado sobre git-deps y herramientas relacionadas, y también hablé públicamente sobre la herramienta varias veces:
Está bastante claro que dos compromisos GIT dentro de un solo repositorio pueden considerarse "independientes" entre sí en cierto sentido, si no cambian los mismos archivos, o si no cambian partes superpuestas de los mismos archivos.
Por el contrario, cuando una confirmación cambia una línea, es "dependiente" no solo de la confirmación que cambió por última vez esa línea, sino también cualquier compromiso que fuera responsable de proporcionar las líneas de contexto circundantes, porque sin esas versiones anteriores de la línea y su contexto, la diferencia del comité podría no aplicarse de manera limpia (dependiendo de cómo se aplique, por supuesto). Por lo tanto, todas las dependencias de un confirmación se pueden inferir programáticamente ejecutando Git-Clama en las líneas que cambian la confirmación, además de que muchas líneas de contexto tienen sentido para el caso de uso de este análisis de dependencia particular.
Por lo tanto, el cálculo de la dependencia se ve afectado por un parámetro de factor de "fuzz" (parche CF (1)), es decir, el número de líneas de contexto que se consideran necesarias para que la diferencia del comet se aplique limpiamente.
Al igual que con muchas relaciones de dependencia, estas dependencias forman bordes en un DAG (gráfico acíclico dirigido) cuyos nodos corresponden a compromisos. Tenga en cuenta que un nodo solo puede depender de un subconjunto de sus antepasados.
Es importante tener en cuenta que cualquier gráfico de dependencia inferido por git-deps puede estar semánticamente incompleto; Por ejemplo, no se detectaría automáticamente dependencias entre un confirmación A que cambia el código y otro Conjunto B que cambia la documentación o las pruebas para reflejar los cambios en el código en el comité A. Por lo tanto, git-deps no debe usarse con fe ciega. Para obtener más detalles, consulte la sección sobre dependencia textual versus semántica (in) a continuación.
A veces es útil comprender la naturaleza de las partes de este gráfico de dependencia, ya que su naturaleza afectará el éxito o el fracaso de las operaciones, incluidas la fusión, Rebase, el sello de cerezas, etc. Consulte el archivo de USE-CASES.md para obtener más detalles.
Consulte el archivo INSTALL.md .
Consulte el archivo USAGE.md .
Los lectores astutos notarán que la independencia textual detectada por git-deps no es la misma que la independencia semántica / lógica. La independencia textual significa que los cambios se pueden aplicar en cualquier orden sin incurrir en conflictos, pero este no es un indicador confiable de la independencia lógica.
Por ejemplo, un cambio en una función y los cambios correspondientes en las pruebas y/o documentación para esa función típicamente existirían en diferentes archivos. Entonces, si esos cambios estuvieran en confirmaciones separadas dentro de una rama, ejecutar git-deps en los compromisos no detectaría ninguna dependencia entre ellos a pesar de que están relacionados lógicamente, porque los cambios en diferentes archivos (o incluso en diferentes áreas de los mismos archivos) son textualmente independientes.
Entonces, en este caso, git-deps no se comportaría exactamente como podríamos querer. Y mientras AI sea un problema sin resolver, es muy poco probable que alguna vez desarrolle un comportamiento totalmente confiable. Entonces, ¿eso significa que git-deps es inútil? ¡En absoluto!
En primer lugar, cuando se cumplen las mejores prácticas para la estructuración de compromiso, los cambios que están fuertemente relacionados lógicamente deben colocarse dentro de la misma confirmación de todos modos. Entonces, en el ejemplo anterior, un cambio en una función y los cambios correspondientes en las pruebas y/o documentación para esa función debe estar dentro de una sola confirmación. (Aunque este no es el único enfoque válido; para un mecanismo de agrupación de metahistoria más avanzado, ver git-dendrify ).
En segundo lugar, si bien la independencia textual no implica la independencia lógica, se espera que lo contrario sea más común: la independencia lógica a menudo implica la independencia textual (o declarada de otra manera, la dependencia textual a menudo implica una dependencia lógica). Entonces, si bien podría no ser demasiado raro que git-deps no pueda detectar la dependencia entre los cambios relacionados con lógicamente, debe ser más raro que infiera incorrectamente una dependencia entre los cambios lógicamente no relacionados. En otras palabras, generalmente se espera que sus falsos negativos sean más comunes que sus falsos positivos. Como resultado, es probable que sea más útil para determinar un límite inferior de las dependencias que un límite superior. Dicho esto, se necesita más investigación sobre esto.
En tercer lugar, a menudo no es útil permitir que la búsqueda de lo perfecto se convierta en enemigo del bien: una herramienta no tiene que ser perfecta para ser útil; Solo tiene que ser mejor que realizar la misma tarea sin la herramienta.
Se puede encontrar más discusión sobre algunos de estos puntos en un hilo antiguo de la lista de correo de Git.
Sin embargo, en última instancia, "la prueba está en el pudín", ¡así que pruébalo y mira!
Consulte el archivo CONTRIBUTING.md .
Consulte el archivo HISTORY.md .
Un agradecimiento especial a SUSE por patrocinar parcialmente el desarrollo de este software. Gracias también a todos los que han contribuido con código, informes de errores y otros comentarios.
Lanzado bajo GPL versión 2 para ser consistente con la licencia de git , pero estoy abierto a la idea de licencias de doble licencia si hay una razón convincente.
