mrsaynothing.dev
Jujutsu vs git: el botón de undo que git nunca tuvo
Deshacer un rebase malo, commitar conflictos, un solo clone con ambas herramientas — el expediente del proyecto leído, no el marketing, no corrido.
■ space · las dos cintas
jj registra cada operación en un op log; jj undo echa atrás un rebase o un reset equivocado — el reflog de git solo rescata commits.
Almacenamiento compatible con git por defecto: un clone, las dos herramientas — remotes, forjas, CI siguen funcionando.
El expediente dice: pruébalo colocalizado en un proyecto aparte; no hay migración a lo bomba — es 0.x, los cambios que rompen llegan con las versiones mensuales.
LAS DOS CINTAS
Pulsa operaciones. La cinta de commits (git) y la cinta de operaciones (jj) graban lado a lado — luego intenta deshacer la última.
las cintas están vacías — pulsa una operación.
GIT · el reflog — commits, ~90 días
el reflog no tiene opinión sobre la secuencia de comandos que produjo el desaguisado — tú eliges el comando inverso: ¿reset? ¿revert? ¿cherry-pick?
JJ · el op log — cada operación
«como todo queda registrado, puedes deshacer con facilidad ese error que acabas de cometer» — la línea del propio README. jj op log · jj undo.
La historia del undo de git asume que elegirás el comando correcto. La de jj asume que no.
QUÉ ES JJ, SEGÚN EL EXPEDIENTE
jj es un VCS compatible con git: 31.796 estrellas en GitHub, 376 colaboradores, primera versión en diciembre de 2020, una versión cada mes desde entonces
de la v0.35 (noviembre 2025) a la v0.45.1, septiembre 2026: doce versiones, como un reloj.
«Compatible con git» es lo que la gente se pierde: jj usa un repo de git como almacenamiento por defecto — los commits y archivos viven en el formato de git. Clones, remotes, forjas y CI siguen funcionando.
La búsqueda «jujutsu vs git» plantea el marco equivocado: jj es una interfaz nueva atornillada al almacenamiento en el que ya confías.
(Meta apostó al revés con Sapling — su propio almacenamiento — y paga más del lado del ecosistema git.)
CONFLICTOS QUE PUEDES COMMITAR
Sí — los conflictos son objetos de primera clase, y eso importa más que la historia del undo. Git trata un conflicto de merge como un estado temporal del working tree: resuélvelo ya o aborta.
jj guarda los conflictos en el historial: un commit en conflicto puede existir, commitarse, incluso empujarse.
Resuélvelo luego; jj propaga el arreglo a cada descendiente — el mismo mecanismo que hace rebase a tu pila.
«PRs apilados con rebases multi-rama sin despeinarse. Los conflictos son cosas de verdad en el historial a las que puedes volver más tarde. Todo se comitea automáticamente, así que no pierdo trabajo por un reset/stash pop mal dado.» — hellcow, Hacker News sobre los hábitos de jj (236 puntos)
Esa última frase es la buena: la copia de trabajo de jj es en sí misma un commit, ajustado con cada cambio.
No existe el stash, porque no hay nada que apuntalar en un stash — cambiar de rama lleva tu trabajo como commit.
Otro converso en un sitio de trabajo solo-git: «0 problemas.»
LO QUE EL EXPEDIENTE DICE CONTRA JJ
- El 0.x, con honestidad. Doce versiones mensuales significan también doce ocasiones al mes de cambios que rompen. El proyecto suelta rápido y lo dice.
- Los bookmarks viven fuera de git. Commits y archivos usan el almacenamiento de git; los metadatos de rama usan el formato propio de jj. Los clones colocalizados tienden el puente — una pieza móvil más que entender.
- 1.262 issues abiertos. Proyecto sano, morral real.
- El escéptico sigue teniendo razón en algo. La reserva con más votos de ese hilo de HN: «Ya he leído sobre jj muchas veces y sigo sin entender qué problema resuelve de verdad.» Si tu flujo git es una rama y un merge ocasional, el op log no te cambiará la semana. Las ganancias llegan con trabajo apilado, historiales en conflicto y días a base de undo.
¿DEBES CAMBIAR?
El veredicto, y la línea de honestidad: he leído el expediente, no lo he corrido.
Cada número y cita aquí viene del repositorio, su README y el hilo de Hacker News — no de mi terminal.
Lo que el expediente respalda: prueba jj colocalizado en un proyecto aparte — un clone, las dos herramientas, cero migración. El conocimiento de git se transfiere; los equipos adoptan persona a persona, ya que jj empuja commits de git corrientes.
Lo que no respalda: una migración a lo bomba de un equipo consolidado, o confiarle a una herramienta 0.x la automatización crítica de las versiones antes de un periodo de fijar y remojar.
El hueco del undo es real, el diseño coherente, la interoperabilidad quita la excusa — queda el hábito.
¿Cambiarías un fin de semana de memoria muscular por un registro de undo que cubra a la propia herramienta?
Y siendo honesto — ¿cuándo fue la última vez que perdiste trabajo por un reset? ¿El reflog lo recuperó todo?
fin de las dos cintas · nada fetchado · todo local