Representando "problemas" en un VCS distribuido

Estoy cansado de todos esos sistemas de seguimiento de problemas que solo se pueden usar en línea o por correo electrónico, así que he estado buscando realizar un seguimiento de los problemas en una database que puede ser replicada y fusionada (para que pueda usarse sin connection).

Para hacer mi vida más fácil, pensé que debería reutilizar las herramientas existentes usando una database así, y me vino a la mente Git. Pero para que funcione bien, es importante que las "fusiones" no generen demasiados conflictos, es decir, que los algorithms incorporados de Git para fusionar twigs se utilicen con prudencia.

A partir de ahora, pensé que los diversos posts en un tema determinado no deberían mantenerse en los files (mantenerlos todos en un solo file generaría conflictos en ese file, y mantenerlos en files separados ocasionaría dificultades para mantenerlos orderados). ) pero en su lugar debe almacenarse en los posts de confirmación, por lo que no puede haber un conflicto debido a esos posts y git log <issue-dir> naturalmente me mostrará los posts en el order correcto.

Pero el problema ahora es que necesito asegurarme de que el post de confirmación esté asociado con el "directory de problemas" correcto (donde guardo el rest de los datos, es decir, principalmente el estado del problema). Para eso necesito asegurarme de que la confirmación modifique algún file en ese directory, pero si el nuevo post no afecta el estado del problema, puede que no haya ningún file que deba ser modificado, así que tendría que articular modificar un file, lo que trae el riesgo de introducir un conflicto. ¿Alguna idea de cómo decirle a Git que un "compromiso vacío" debería estar asociado con un subdirectory en particular?

Hay varios rastreadores de errores que funcionan dentro del control de su versión; Bugs Everywhere es el que viene a la mente. Con Bugs Everywhere, coloca los informes de errores en el mismo repository que el código. Cada informe de error es un file separado, y generalmente se edita con el progtwig de línea de command be. Esto funciona de manera muy natural con la bifurcación que ya está haciendo en su repository, porque puede verificar una sucursal y ver el estado de todos los errores en ese momento.

Almacenar los informes de errores en el post de confirmación parece un ajuste pobre. ¿Cómo se actualiza un error? No puede actualizar un post de confirmación sin invalidar cada confirmación siguiente.

No creo que pueda evitar conflictos de combinación con su layout; Tendrás que obligar a quien detecte el conflicto de fusión a volver a establecer sus cambios en el error antes de presionar.

De acuerdo, no encontré una forma clara de vincular el post de una confirmación vacía con un directory en particular, excepto agregar un file ficticio que era demasiado feo para mi gusto.

Pero terminé resolviendo un problema ligeramente diferente: en lugar de tener un directory por cada error, coloqué cada error en su propia twig . De esta manera, no hay necesidad de realizar ninguna gimnasia para unir los posts de compromiso con errores particulares. Además, eso evita intercalar artificialmente posts de confirmación de diferentes errores, y hace posible git merge errores, o compartir algún subset de errores entre diferentes bases de datos de errores.

Si está interesado, he puesto mi código en https://gitlab.com/monnier/bugit