El creador de Jujutsu se ha unido a ERSC

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

La contratación por parte de la startup de control de código fuente orientada a empresas ERSC ha llamado la atención sobre Jujutsu (“jj”), un sistema de control de versiones compatible con Git que promete flujos de trabajo más seguros e intuitivos con funciones como deshacer universal, resolución diferida de conflictos y reestructuración de commits más sencilla. Los comentaristas exploran cómo el diseño de jj, apoyado en Git, reduce los costes de cambio en comparación con alternativas anteriores a Git, mientras ERSC pretende construir un backend de próxima generación para monorepos grandes y desarrollo asistido por IA en lugar de un sitio de codificación social como GitHub. El hilo también plantea preocupaciones sobre la CLA de contribuyentes de Google en torno a jj, problemas de rendimiento y accesibilidad en el sitio de marketing animado de ERSC, y si las empresas adoptarán un nuevo proveedor en una capa de herramientas tan fundamental.

Aclaraciones sobre ERSC, JJ y Google

  • JJ (Jujutsu) es un VCS OSS bajo Apache 2.0 que actualmente usa el formato y el protocolo en disco de Git, pero con algoritmos y UX diferentes.
  • Google no posee los derechos de autor; los contribuyentes los conservan. La CLA de Google otorga a Google amplios derechos de licencia, pero no es una cesión de derechos de autor.
  • La organización de GitHub se trasladó desde una cuenta personal; Google sigue controlando la org principalmente para mantener el bot de la CLA, y posee la marca registrada “jj”.
  • La nueva contratación dejó Google para unirse a ERSC, pero sigue siendo un mantenedor principal de JJ. Los mantenedores equilibran intencionalmente la representación de las empresas.

Dirección del producto de ERSC

  • ERSC se posiciona como “control de código fuente de próxima generación para la empresa”, no como un sitio de codificación social ni como un competidor directo de GitHub.
  • Áreas de enfoque: escalar más allá de los límites de Git para monorepos grandes, ACL por directorio y flujos de trabajo a nivel de organización, especialmente en entornos “agentic”/muy centrados en LLM.
  • Están construyendo un nuevo backend (comparado con los sistemas internos de Google) con entrada/salida de Git para una adopción incremental; JJ es el cliente puente.
  • La estrategia inicial de comercialización es solo para empresas, con ventas y onboarding, aunque no se bloqueará explícitamente a particulares. La CI será “trae la tuya” al principio.

Discusión técnica: JJ vs Git (y Mercurial)

  • JJ ofrece:
    • Conflictos de primera clase almacenados en commits, lo que permite una resolución de conflictos diferida e incremental.
    • Un registro transaccional de operaciones que admite undo universal (para rebases, merges, resoluciones de conflictos, etc.), más allá del reflog de Git.
    • Rebase automático de commits/ramas dependientes cuando cambia el historial.
    • Un modelo unificado para el working copy, el comportamiento similar al index, los stashes y los conflictos.
  • El seguimiento de copias/renombres y otras funciones están en desarrollo activo.
  • En comparación con Mercurial, JJ aspira a ser más rápido y gana tracción gracias a una compatibilidad fluida con Git.

Adopción, UX y flujos de trabajo

  • Sus defensores informan que editar el historial es drásticamente más fácil (reordenar, dividir, apilar commits), que la experimentación es más segura y que el manejo de conflictos es mejor.
  • Algunos dicen que los comandos principales de Git más una GUI ya son suficientes, y que rara vez se encuentran con problemas en los que las ventajas de JJ importen.
  • Hay debate sobre la UX de Git: algunos creen que está bien una vez que aprendes teoría de VCS; otros ven a JJ como un modelo mental mucho más claro.
  • JJ puede usarse unilateralmente en repositorios Git; los compañeros no necesitan cambiar. Se elogian herramientas TUI (como jjui).

Preocupaciones sobre licencias, gobernanza y propiedad

  • Algunos temen que la CLA de Google y la marca registrada creen una “Espada de Damocles” y posibles señales de alerta para inversores.
  • Otros argumentan que Apache 2.0, junto con derechos de autor distribuidos y la posibilidad de hacer fork/renombrar, mitigan el riesgo real de bloqueo.

Comentarios sobre diseño y rendimiento del sitio web

  • Muchos elogian la estética y la baja latencia del nuevo sitio de ERSC.
  • Otros informan un uso severo de GPU y un mal rendimiento al desplazarse en varios navegadores/SO; el fondo animado se cita como el culpable y como un problema de accesibilidad.
  • ERSC reconoce los problemas, impulsa correcciones (incluida la eliminación/reducción de la animación) y pretende respetar las preferencias de reducción de movimiento.