Git-bug: Rastreador de errores distribuido, offline-first, integrado en Git

Artículo original ↗ Discusión en Hacker News ↗

Una nueva herramienta llamada git-bug integra un rastreador de errores distribuido y offline-first directamente en repositorios Git, con el objetivo de mantener las incidencias versionadas y portables junto con el propio código. Quienes comentan sopesan sus beneficios —proyectos autocontenidos, sin dependencia de SaaS, resolución de conflictos basada en CRDT y posibles extensiones como pull requests y CI— frente a desafíos prácticos como la usabilidad para partes interesadas no técnicas, la gestión de identidades, la integración SSH y los límites de vincular los tickets demasiado estrechamente a las ramas. Las comparaciones con sistemas como Fossil, Gerrit y los rastreadores centralizados tradicionales resaltan una pregunta más amplia: si el rastreo de incidencias puede descentralizarse de forma efectiva sin sacrificar accesibilidad y simplicidad en el flujo de trabajo.

Recepción general y concepto

  • A muchos les resulta muy atractiva la idea de un rastreador de incidencias distribuido y offline-first dentro de Git, especialmente para equipos pequeños y flujos de trabajo local-first.
  • A la gente le gusta que las incidencias puedan viajar con el repositorio, versionarse y permanecer independientes de cualquier forge SaaS concreta.
  • Algunos sostienen que los tickets son parte integral de la historia del código (especialmente los errores resueltos), lo que hace atractivo coubicarlos con el código.

Nombre y alcance (“bug” vs “todo”)

  • Varios señalan que “git bug” suena limitado para solicitudes de funcionalidad, PRs y otros flujos de trabajo.
  • Otros apuntan que muchos rastreadores históricos usan “bug” para todo tipo de incidencias, y eso ha funcionado bien en la práctica.
  • La nomenclatura actual de la CLI (por ejemplo, un posible git bug bug frente a git bug pr) se ve como incómoda, pero no como un impedimento.

Desafíos del rastreo distribuido de incidencias

  • Intentos anteriores de rastreadores distribuidos a menudo fracasaron, sobre todo por el manejo de merges/conflictos y la colaboración entre ramas.
  • Hay debate sobre vincular incidencias a ramas frente a un espacio compartido; las incidencias específicas de rama mejoran la precisión, pero oscurecen el estado compartido.

Modelo de datos, CRDTs e integración con Git

  • El proyecto evita deliberadamente los conflictos de merge crudos de Git para los tickets, usando en su lugar operaciones estilo CRDT.
  • La razón: para interacciones sociales, capturar la intención del usuario y evitar la resolución manual de conflictos es más importante que fusionar el texto con exactitud.
  • El espacio de nombres flexible de refs de Git es elogiado; las incidencias viven junto a ramas/tags sin cambiar el núcleo de Git.

Modelo de identidad y seguridad

  • El modelo de nombre/correo/firma de Git se considera demasiado débil para un sistema social peer-to-peer y offline-first.
  • El proyecto tiene su propia capa de identidad con claves públicas y una migración planificada a infraestructura basada en DID para compartir identidades entre repos.
  • Se debate la posibilidad de verificar también los commits de código usando estas identidades en el futuro.

Usabilidad, accesibilidad y UI web

  • Algunos argumentan que los rastreadores de incidencias deben ser ampliamente accesibles; atarlos a Git/CLI puede excluir a quienes no son desarrolladores.
  • Otros sugieren que una UI web con OAuth/OIDC (y posiblemente estándares de federación) es esencial para que se sienta como un rastreador alojado normal, aunque por debajo siga siendo local-first.
  • Se proponen aplicaciones de escritorio o frontends web en contenedores Docker para reducir la exposición a Git para usuarios no técnicos.

Red, SSH y problemas de implementación

  • Un error que requiere un agente SSH para push/pull es calificado como un “showstopper” por algunos; otros lo ven como algo menor.
  • La preocupación se centra en no usar el SSH del sistema, lo que rompe configuraciones complejas de ~/.ssh/config (ProxyJump, múltiples identidades, bastiones).
  • El autor indica planes de volver a invocar el binario de Git (o algo similar) en lugar de la biblioteca actual, posiblemente por defecto.

Funciones de flujo de trabajo y limitaciones

  • El estado binario actual abierto/cerrado se considera demasiado limitado; hay interés en estados configurables y operaciones/entidades extensibles.
  • El modelo de datos está diseñado para que se puedan añadir nuevas operaciones/entidades sin romper clientes antiguos.

Motivación frente a servicios centralizados

  • Quienes lo apoyan valoran la independencia de SaaS, la velocidad offline y tener un proyecto completo autocontenido.
  • Quienes lo critican argumentan que los rastreadores web centralizados son mejores para un acceso amplio, y que alinear el ciclo de vida de los bugs con la historia de Git suele ser artificial.
  • Una preocupación: exigir permisos de Git (p. ej., force-push) para que personas no programadoras editen tickets viola los límites de roles existentes.

Monetización y ecosistema

  • Se considera difícil convertir esto en trabajo a tiempo completo; venderlo a empresas se ve complicado.
  • Algunos sugieren nichos: proyectos de hobby, repos aptos para LLM o un nivel “enterprise” con soporte.
  • Hay discusión activa sobre extenderlo a pull requests, CI y capacidades tipo forge.

Alternativas y proyectos relacionados

  • Se mencionan múltiples antecedentes y herramientas afines: Fossil, otros rastreadores basados en Git, sistemas de revisión, forges de metadatos basados en CRDT y sistemas de tickets basados en archivos.
  • Fossil se cita como prueba de que un VCS+rastreador integrado puede funcionar bien, aunque sus opiniones fuertes (por ejemplo, no reescribir el historial) limitan su adopción para algunos.
  • Algunos usuarios prefieren rastreadores más simples, basados en texto o JSON, almacenados en ramas o repos dedicados, defendiendo la separación de responsabilidades y el mínimo de magia.