> Jujutsu v0.46, analizado: qué cambió y quién debería moverse▋

Hace dos semanas este sitio leyó el registro de jj por primera vez y lo llamó el botón de undo que git nunca tuvo — 31.796 estrellas, releases mensuales, un registro de operaciones. Hoy, la segunda lectura: 32.012 estrellas (+216 en la quincena), la v0.46.0 salió hace seis días, y el repositorio recibió push a las 05:22 UTC de esta mañana, antes de que hiervara la tetera.

La línea de honestidad, igual que la última vez: leí el registro, no ejecuté la herramienta. Todo lo que sigue viene de las notas de la v0.46.0, del registro público del repositorio y de nuestra primera lectura. Lo que aporta una segunda lectura es lo que una primera no puede tener: un delta. Dos semanas de releases, dos semanas de estrellas, dos semanas de nuestros propios datos de búsqueda acumulándose detrás de la misma pregunta.

Y la mentira que este post rechaza: que un número de versión sea una noticia. La mayoría de las point releases son plomería. La v0.46.0 no — cambia el cálculo de cambiar, y los datos de demanda de la quincena explican por qué importa más de lo que el changelog admite.

¿Qué cambió en Jujutsu v0.46? Los workspaces ya pueden colocarse mediante worktrees de git reales (jj workspace add --colocate), jj undo/jj redo rechazan operaciones cross-workspace por defecto, jj bisect run verifica sus dos extremos, y el git mínimo subió a 2.42.0. Los repositorios colocados siguen siendo git normal para GitHub y tus compañeros.

El registro de la quincena

Los números primero, porque son la única parte de este post que nadie puede discutir.

la medida	primera lectura (29 sep)	segunda lectura (13 oct)
estrellas en GitHub	31.796	32.012 (+216 / 14 días ≈ 15/día)
última release	v0.45.1 (3 sep)	v0.46.0 (7 oct — una brecha de 34 días)
último push del repositorio	activo	05:22 UTC hoy
issues abiertos	—	1.260

Las estrellas son vanidad, la cadencia es señal: dos releases en seis semanas con breaking changes bien listados es un proyecto que entrega y te dice qué rompió. Los 1.260 issues abiertos se leen igual — una herramienta en movimiento, no una herramienta terminada.

Nuestro propio registro carga la segunda señal. La familia de impresiones más grande del clúster de git este mes sigue siendo deshacer un commit conservando los cambios — impresiones subiendo 100 % semana contra semana, y casi cero clics, porque la respuesta honesta de git está a tres comandos de profundidad y los lectores lo notan. La demanda de undo no esperó a jj. Nunca espera.

Jujutsu vs git: la tabla del undo

La primera lectura explicó el modelo — la copia de trabajo es un commit, cada operación escribe en el registro de operaciones, los conflictos son de primera clase. Lo que se saltó, y lo que los datos de búsqueda dicen que la gente necesita de verdad a las 6 de la mañana, es la tabla a nivel de frases: el trabajo, tecleado como lo teclean quienes buscan, en ambos dialectos.

el trabajo	git (el conjuro)	jj (la operación)
deshacer lo último que hice	reflog, entrecerrar los ojos, reset --soft o reset --keep	jj undo
deshacer el deshacer	no hay camino limpio	jj redo
ver qué acaba de pasar	git reflog	jj op log
enmendar el último commit	git commit --amend	edita los archivos — el commit de copia de trabajo se enmienda solo
guardar un conflicto para después	no permitido — resuélvelo ahora o detente	los conflictos son commits; resuélvelos cuando quieras

En git, deshacer es arqueología — excavar el reflog, encontrar el shard, reconstruir. En jj, la cinta nunca estuvo enterrada: deshacer es una operación sobre el registro de operaciones. Excavación contra un botón de rebobinar.

imagínalo: git te da la grabadora de vuelo — montada detrás del avión, legible después del accidente. jj la montó en el tablero y la conectó a un botón de rebobinar.

v0.46.0: los dos cambios que importan

Workspaces que se colocan mediante worktrees de git reales. jj workspace add --colocate (o el ajuste git.colocate) pone un workspace de jj al lado de un checkout de git normal sin quedarse con el clon. Léelo como un carril de entrada que se ensancha: un equipo puede correr un workspace de jj junto a un checkout de git en la misma máquina, el mismo repositorio, y comparar — exactamente la prueba que pedía el veredicto de la primera lectura. Se apoya en git worktree add --orphan, por eso el git mínimo sube a 2.42.0.

Un undo que conoce sus límites. jj undo y jj redo ahora se niegan a tocar operaciones de otro workspace a menos que pases --allow-cross-workspace. Que una herramienta cuyo argumento entero es "el undo es seguro" apriete las guardas alrededor del undo es la prueba de cultura superada. El resto de las notas se lee igual: jj bisect run verifica sus extremos bueno y malo antes de caminar, y jj split deja de hacer malabares con sesiones de editor.

Prueba la grabadora sin arriesgar nada

En un clon desechable, corre jj git init --colocate — aparece un directorio .jj junto a .git, git sigue funcionando exactamente igual, y jj op log muestra la grabadora corriendo. Nada cambia del lado de git; la puerta de salida es rm -rf .jj.

verificación: jj op log en ese clon lista tus operaciones con marcas de tiempo — una línea por comando significa que el registro es real en tu máquina, no solo en la documentación.

El registro honesto: qué se rompe

La memoria muscular, primero. La danza del index — git add -p, el staging parcial — se traduce al squash y split de jj, que resuelven el mismo problema con otras manos. La primera semana teclearás verbos de git y estarás molesto.

La óptica de equipo, después. Los repositorios colocados se ven como git normal para el hosting y para los compañeros — pero los commits de copia de trabajo de un usuario de jj solo se vuelven visibles al hacer push, y "¿dónde está mi trabajo a medio hacer?" recibe una respuesta distinta de la que la gente de git espera. Los equipos pequeños se encogen de hombros; los monorepos con tooling profundo deberían esperar. El rechazo cross-workspace del undo en la v0.46 es un límite más que aprender — deliberadamente, y honestamente, la decisión correcta.

Y el recibo que sigue faltando: benchmarks. A dos lecturas, la afirmación sigue sin hacerse. No puedo decirte que el rebase de jj le gana al de git en un repositorio de 10.000 commits, porque no lo he corrido — ese número no existe hasta que exista el bench, y una segunda lectura no convierte una lectura de registro en bench.

Veredicto, revisado: quién debería moverse esta semana

La primera lectura decía: pruébalo. Dos semanas y una release después, el cálculo se movió en exactamente una dirección — la colocación worktree de la v0.46 bajó el costo de la prueba misma, y los datos de demanda se endurecieron. La familia del undo que sigue nuestro tablero no se enfrió una sola impresión; la herramienta que la responde en un comando entregó dos veces. Cuando una brecha tan ancha sigue abriéndose, alguien la va a cerrar. jj la cierra a nivel de modelo, no de regla mnemotécnica — la comparación completa vive en el hub de git-undo, junto a la decisión clásica que perturba: revert vs reset, que ahora tiene una tercera respuesta, y la tercera respuesta es un botón.

Muévete ahora: desarrolladores en solitario y equipos pequeños con cicatrices de undo; cualquiera que enseñe git y esté cansado de ver caer las caras ante el reflog; y — el carril que más vigilamos — los repositorios manejados por agentes, donde cada operación debería ser reversible y auditable por defecto. Un registro de operaciones ahí no es comodidad; es la superficie de auditoría que git nunca entregó.

Espera: cadenas profundas de tooling de git, suposiciones de CI cargadas de hooks, quien esté a mitad de migración. Y espera el bench — el próximo artículo de jj de este sitio enfrentará jj contra git en un repositorio real e imprimirá el número más feo primero, porque el registro de la quincena compró el beneficio de la duda exactamente una vez.

Dos preguntas antes de ese bench: ¿un rescate por reflog te falló alguna vez en el peor momento — y si corres jj en serio este mes, qué se rompe primero? Los comentarios están abiertos; dinos qué probar.