Jujutsu vs Git: el botón de deshacer que Git nunca tuvo

El reflog de git salva tus commits. No te salva de la orden que corriste sobre ellos. Esa brecha — deshacer la operación, no solo el commit — es todo el argumento de Jujutsu, y después de leer el expediente del proyecto en vez de su marketing, el argumento aguanta mejor de lo que creen sus escépticos.

El hub Undo Anything in Git de este sitio existe porque la historia de deshacer en git está fragmentada: reset, revert, reflog, cada uno con sus reglas. La apuesta de jj es que esa fragmentación es un bug de diseño.

¿Qué es Jujutsu y por qué compararlo con git?

jj es un sistema de control de versiones compatible con Git: 31,796 estrellas en GitHub, 376 colaboradores, primer release en diciembre de 2020, y un release nuevo cada mes desde entonces — de la v0.35 en noviembre de 2025 a la v0.45.1 en septiembre de 2026, doce releases que caen en la primera semana del mes sin fallar. Su último commit se subió la mañana en que este post salió.

“Compatible con Git” es la parte que se pierde. jj usa un repositorio Git como backend de almacenamiento por defecto — el README lo dice explícito: los commits y los archivos viven en formato git, así que tu clon, tus remotes, tus forjas y tu CI siguen funcionando. La pregunta de jujutsu vs git que todos buscan es el marco equivocado: jj está más cerca de una interfaz nueva conectada al almacenamiento en el que ya confías. El Sapling de Meta apostó al revés con su propio backend de almacenamiento, y por eso mudarse hacia él deja atrás más del ecosistema git.

¿Qué hace el registro de operaciones que git no puede?

Esa es la decisión de diseño que vale toda la reseña. Git registra commits en el reflog — el trabajo botado por accidente se recupera durante unos 90 días. Pero al reflog no le importa la secuencia de comandos que produjo el desastre. La decisión revert-vs-reset existe porque git te hace escoger el comando de deshacer correcto antes de saber cuál necesitabas.

jj registra cada operación — cada rebase, cada abandon, cada squash — en un registro de operaciones. La línea del propio README: “como todo queda registrado, puedes deshacer con facilidad el error que acabas de cometer.” jj op log muestra la historia del estado del repositorio, y jj undo retrocede por ella. ¿Rebase equivocado? Undo. ¿Reset al lugar incorrecto? Undo. La herramienta se extiende a sus propias acciones la misma seguridad que git extiende a tus datos.

La historia de deshacer de git asume que escogerás el comando correcto. La de jj asume que no.

¿Los conflictos son realmente de primera clase?

Sí, y cambia los flujos de equipo más que la historia de deshacer. Git trata un conflicto de fusión como un estado temporal del árbol de trabajo — lo resuelves ahora o abortas. jj guarda los conflictos como objetos en la historia: un commit en conflicto puede existir, hacerse commit, incluso subirse. Resuelves el conflicto después y jj propaga la resolución a todos los descendientes automáticamente — el mismo mecanismo que rebasea tu pila cuando editas un commit antiguo.

El resultado en un proyecto real — cambios apilados que se rebasean solos — es lo que convierte a la gente. Del hilo de Hacker News sobre patrones de jj (236 puntos):

“Los PRs apilados con rebases multi-rama son triviales. Los conflictos son cosas reales en la historia a las que puedes volver después. Todo se hace commit automáticamente, así que no pierdo trabajo por un reset/stash pop mal dado.” — hellcow

Esa última oración es la que hay que masticar. La copia de trabajo de jj es en sí un commit, corregido con cada cambio. No hay stash porque no hay nada que stashar — cambiar de rama lleva tu trabajo en curso como commit. Otro comentarista que cambió en el trabajo, con un equipo 100% git: “hubo 0 problemas.”

¿Qué dice el expediente en contra de jj?

El registro honesto, porque el expediente tiene uno:

• Versión 0.x, sin maquillaje. Doce releases mensuales también significan doce oportunidades al mes de cambios que rompen. El proyecto avanza rápido y lo dice.
• Los bookmarks viven fuera de git. Los commits y archivos usan almacenamiento git; los metadatos de ramas usan el formato propio de jj. Los clones colocados hacen el puente, pero es una pieza más que entender.
• 1,262 issues abiertas. Proyecto sano, backlog real.
• El escéptico sigue teniendo razón en algo. La reserva con más votos de ese hilo de HN: “He leído sobre jj tantas veces que sigo sin entender qué problema resuelve.” Si tu flujo git es una rama y un merge de vez en cuando, el registro de operaciones no te cambiará la semana. Las ganancias llegan con trabajo apilado, historias en conflicto y días de deshacer — los días en que el generador git undo recibe tráfico.

¿Deberías cambiar de git a jj?

El veredicto del expediente, con la línea de honestidad obligatoria: leí el expediente, no lo ejecuté. Cada número y cada cita vienen del repositorio, su README y el hilo público de HN — no de mi terminal.

Lo que el expediente sostiene: prueba jj colocado en un proyecto personal — un clon, dos herramientas, cero migración. Tu conocimiento de git se traslada, porque los objetos de abajo son los de git. Los equipos pueden adoptarlo persona por persona, ya que jj sube commits de git corrientes al upstream. Lo que el expediente no sostiene: una migración big-bang de un equipo establecido, o confiarle automatización crítica a una herramienta 0.x antes de un periodo de prueba con versión fijada.

La brecha de deshacer es real y el diseño es coherente; la interoperabilidad quita la excusa de siempre, y queda el hábito como último obstáculo.

¿Cambiarías un fin de semana de memoria muscular por un registro de deshacer que cubre a la propia herramienta? Y siendo honestos — la última vez que perdiste trabajo con un reset, ¿el reflog lo recuperó todo?