History bearbeiten, ohne die Luft anzuhalten

Teil 7 von 9.

Die drei Züge, die diese Lektion behandelt, neue Arbeit beginnen, bestehende Arbeit bearbeiten, neue Arbeit von einem Punkt in der Vergangenheit aus beginnen, bilden Dinge ab, die ich in Git ohnehin ständig getan habe. Der Unterschied ist, wie sehr ich mich früher darauf gefasst gemacht habe.

jj new, das die aktuelle Arbeitskopie abschließt und eine leere öffnet, ist unspektakulär, im Grunde git commit mit entferntem Staging-Schritt. Der, der verändert hat, wie ich arbeite, ist jj edit <change-id>. Etwas zwei Commits zurück zu korrigieren bedeutete früher git rebase -i, edit in der richtigen Zeile auswählen, die Korrektur machen, git rebase --continue und hoffen, dass unterwegs nichts weiter unten in Konflikt geriet. Mit jj verschiebt jj edit einfach die Arbeitskopie auf diesen Commit. Jede Datei, die ich anfasse, ergänzt ihn direkt. Nachfahren werden automatisch rebasiert, sobald jj mir den Graphen das nächste Mal zeigen muss. Kein Detached-HEAD-Zustand, kein mehrstufiger Rebase, den man auf halbem Weg abbrechen muss, wenn ich meine Meinung ändere, jj undo deckt das ab.

Neue Arbeit von einem vergangenen Commit statt von @ aus zu beginnen, war der, der sich von Git kommend am ungewohntesten anfühlte, hauptsächlich weil Git das Äquivalent (einen alten Commit auschecken, dann davon branchen) wie eine besondere, leicht riskante Operation wirken lässt. In jj ist es einfach jj new <old-change-id>, und das Log zeigt sofort eine Verzweigung, zwei echte Heads, die sich einen Vorfahren teilen, keiner gegenüber dem anderen privilegiert. Nichts zwingt mich, gleich zu entscheiden, ob diese zweite Arbeitslinie ein Bookmark wird, zurückgemerged wird oder aufgegeben wird. Diese Eigenschaft der aufgeschobenen Entscheidung ist das, von dem ich nicht erwartet hatte, dass ich es so schätzen würde, wie ich es tue: Der Moment, in dem “lass mich das kurz von main aus prüfen” mitten in einer Aufgabe aufkommt, ist ein einzelner Befehl statt eines Stash-und-Wechsel-Tanzes.