Editar el historial sin contener la respiración

Parte 7 de 9.

Los tres movimientos que cubre esta lección (empezar trabajo nuevo, editar trabajo existente, empezar trabajo nuevo desde un punto del pasado) se corresponden con cosas que ya hacía constantemente en Git. La diferencia es cuánto solía prepararme para ellas.

Que jj new cierre la copia de trabajo actual y abra una vacía no tiene nada de notable, es básicamente git commit con el paso de staging eliminado. El que cambió cómo trabajo es jj edit <change-id>. Arreglar algo dos commits atrás solía significar git rebase -i, elegir edit en la línea correcta, hacer el arreglo, git rebase --continue, y esperar que nada más abajo entrara en conflicto por el camino. Con jj, jj edit simplemente mueve la copia de trabajo a ese commit. Cualquier archivo que toque lo enmienda directamente. Los descendientes reciben rebase automáticamente la próxima vez que jj necesite mostrarme el grafo. Sin estado de HEAD desanclado, sin un rebase de varios pasos que abandonar a mitad de camino si cambio de opinión: jj undo cubre eso.

Empezar trabajo nuevo desde un commit pasado en lugar de desde @ fue lo que se sintió más ajeno viniendo de Git, sobre todo porque Git hace que el equivalente (hacer checkout de un commit antiguo y luego ramificar desde él) se sienta como una operación especial y ligeramente arriesgada. En jj es simplemente jj new <old-change-id>, y el log muestra de inmediato una bifurcación: dos cabezas reales que comparten un ancestro, ninguna privilegiada sobre la otra. Nada me obliga a decidir de inmediato si esa segunda línea de trabajo se convierte en un bookmark, se vuelve a fusionar, o se abandona. Esa propiedad de decisión aplazada es lo que no esperaba valorar tanto como lo hago: el momento en que “déjame comprobar esto rápido desde main” surge a mitad de una tarea, es un solo comando en lugar de un baile de stash y cambio.