Ask HN: ¿Podemos hacerlo mejor que Git para el control de versiones?

Discusión en Hacker News ↗

La dominancia de Git como sistema de control de versiones está ampliamente reconocida, pero muchos ingenieros argumentan que está lejos de ser ideal, especialmente en términos de usabilidad, manejo de grandes activos binarios y soporte para monorepos enormes. Los comentaristas señalan alternativas como Fossil, Mercurial, Perforce, Pijul, Jujutsu y Sapling, así como capas de interfaz y herramientas construidas sobre Git, como evidencia de que son posibles mejores flujos de trabajo y modelos. La visión predominante es que los efectos de red y el ecosistema de GitHub hacen poco probable un reemplazo total en el corto plazo, por lo que la innovación práctica se centra en interfaces mejoradas, fusiones más inteligentes y sistemas especializados para activos que no son código, en lugar de abandonar Git por completo.

Sentimiento general sobre Git

  • Muchos consideran que Git es “suficientemente bueno” y probablemente dominante durante mucho tiempo por su ubicuidad y ecosistema, no porque sea ideal.
  • Otros sostienen que está lejos de ser un problema resuelto: interfaz confusa, valores predeterminados deficientes y algunas limitaciones arquitectónicas reales.
  • Varios comentarios señalan que Git sustituyó sistemas peores (RCS/CVS/SVN) y resolvió problemas importantes, pero ahora él mismo parece anticuado.

UX, modelo mental y curva de aprendizaje

  • Quejas repetidas sobre conceptos y comandos confusos: commit vs push vs pull vs fetch, área de staging, rebase, reflog, etc.
  • Algunos quieren un “modo fácil” más simple con un pequeño conjunto de comandos seguros (“guardar / actualizar”) y un “modo experto” para operaciones avanzadas.
  • Hay tensión entre “herramientas para profesionales, la complejidad está bien” y “una mala UX hace perder tiempo y no está justificada”.
  • Las GUIs y las herramientas de nivel superior (IDEs, aplicaciones de escritorio, frontends TUI, wrappers como Graphite, Magit, etc.) se ven como formas efectivas de domar Git.

Puntos de dolor técnicos y arquitectónicos

  • Archivos grandes y activos binarios: Git LFS se considera torpe y frágil; los flujos de trabajo de desarrollo de videojuegos y CAD a menudo prefieren Perforce o SVN.
  • Monorepos muy grandes: problemas de rendimiento con los escaneos de estado, el tamaño del historial y muchos archivos; los atajos incluyen sistemas de archivos virtuales, clones parciales/sparsos y herramientas específicas de proveedores.
  • Resolución de conflictos: los algoritmos de fusión actuales se consideran “rápidos pero tontos”; modelado limitado de los conflictos (sin un “estado en conflicto” como entidad de primera clase), renombres difíciles y falta de comprensión semántica.
  • Modelo de almacenamiento: instantáneas de blobs frente a sistemas basados en parches; algunos sostienen que los sistemas basados en parches (Darcs, Pijul) permiten mejores fusiones y razonamiento sobre el historial.

Alternativas y sistemas nuevos

  • Mencionados con frecuencia: Fossil (tickets/wiki integrados, historial inmutable), Mercurial y derivados (Sapling, sistemas internos de Google), Darcs, Pijul, Jujutsu, Perforce y herramientas específicas de dominio (por ejemplo, Oxen para grandes conjuntos de datos de IA).
  • Algunas herramientas nuevas siguen siendo compatibles con Git a nivel de almacenamiento/protocolo, pero ofrecen nuevas UIs o semánticas, y se consideran más adoptables que un cambio radical.

Alojamiento, centralización y efectos de red

  • El dominio de Git está estrechamente ligado a GitHub y forjas similares; la descubribilidad y las contribuciones sufren fuera de GitHub.
  • Alternativas como GitLab, Forgejo/Gitea, SourceHut, Codeberg y el alojamiento de Fossil existen, pero luchan contra los efectos de red.
  • Se menciona la federación entre forjas como una posible forma de reducir la dependencia.

Direcciones futuras

  • Ideas planteadas: diffs/fusiones semánticas, almacenamiento de código basado en AST, historial de ramas como objeto de primera clase, mejor seguimiento del historial físico, rastreo de movimientos integrado en el editor y flujos de trabajo más centrados en lo centralizado.
  • No está claro si alguna de ellas ganará suficiente impulso como para reemplazar Git; superponer mejoras sobre Git se considera la vía más realista a corto plazo.