El creador de Typst lleva seis meses usando jj junto a Git para limpiar sus pull requests
Repasa qué le convence de Jujutsu (editar la historia, el undo, jjui) y qué le frena (el log, el detached HEAD o los snapshots accidentales de node_modules).
El creador de Typst lleva unos seis meses usando jj (Jujutsu) en paralelo a Git, y su conclusión es que no hace falta migrar del todo. Lo usa solo para una tarea: dejar limpio el historial de commits de sus pull requests. No ha abandonado Git y sostiene que eso habla tanto de él como de la herramienta.
El objetivo era tener un flujo mejor que el que tenía, repartido entre rebase interactivo, arrastrar commits en GitHub Desktop y tocar Tower. Con jj quería historiales más ordenados, y dice que le ha servido bien.
Lo que le convence
Editar la historia. Mover y reescribir commits le resulta mucho más fluido, sobre todo con jjui, una interfaz para terminal que usa más que la propia línea de comandos. No tiene memorizados los comandos de jj porque con los atajos de jjui le basta.
Le gusta también que haya comandos específicos para conceptos concretos, como jj split, en lugar de meterlo todo bajo operaciones genéricas. Y destaca undo: sirve para recuperar trabajo perdido, algo que le ha pasado varias veces, pero también para probar cómo quedan los conflictos y deshacer sin más. En Git se puede hacer algo parecido guardando un SHA o tirando del reflog, aunque le resulta menos cómodo.
Lo que le frena
El log. La salida de jj log en su repositorio principal, typst/typst, le muestra por defecto las ramas de otras personas que revisó hace poco, y le cuesta encontrar su propio trabajo o ver la historia de la rama actual. Ha tocado el revset por defecto y algo ha mejorado, pero el problema es nuevo para él.
Le molesta además que al saltar entre Git y jj se quede en detached HEAD, incluso cuando el cambio editado está vacío, y que al añadir commits con jj la rama no avance sola.
El auto-snapshot también le ha dado guerra. Que jj fotografíe el disco en cada comando evita perder trabajo, pero es un efecto secundario: puede disparar un rebase y tocar el historial de undo, hasta el punto de que da igual pulsar una o dos veces sobre el terminal antes de editar código. Y es fácil fotografiar sin querer un node_modules que acabas de añadir al gitignore: si luego editas un commit antiguo, aparece dentro. Hay heurísticas para detectar archivos grandes, pero no todo lo que sobra es grande.
Queda el comportamiento de los merges de cambios idénticos, que también existe en Git, aunque ahí nunca se lo encontró, probablemente porque no forzaba rebases tan agresivos.
Lo relevante quizá sea lo que no ha pasado: no ha migrado. jj es interoperable con Git hasta el punto de convivir con él, y eso es lo que le permite usarlo como herramienta de limpieza y volver a Git cuando se atasca. Para quien arrastre un historial de pull requests desordenado, la puerta de entrada es esa convivencia, no el salto completo.
