Colocated-Modus: zwei Speicher, ein Verzeichnis

Teil 2 von 9.

Die Installation selbst ist ein Nicht-Ereignis, ein Paketmanager oder ein cargo install, dann eine user.name/user.email-Konfiguration, dieselbe Form wie Gits eigenes Erst-Setup. Der interessante Teil beginnt bei jj git init --colocate.

Führe das innerhalb eines bestehenden Git-Checkouts aus, und es legt ein .jj-Verzeichnis neben .git an, fügt .jj/ zu .git/info/exclude hinzu, damit es nie als untracked auftaucht, und importiert die aktuellen Branches und HEAD als jj-Commits. Nichts in .git wird umgeschrieben. Wenn ich .jj jetzt sofort löschte, wäre das Repository genau das schlichte Git-Repo, das es vorher war, nichts verloren.

Diese Umkehrbarkeit ist es, die das Ausprobieren risikoarm anfühlen ließ. Es ist keine Migration mit einem Punkt ohne Wiederkehr; es ist eher, als würde man einen zweiten Leser über einen bereits existierenden Speicher installieren. git log funktioniert weiter. git status funktioniert weiter. Jeder Pre-Commit-Hook, jeder CI-Runner, die IDE jedes Kollegen funktioniert ohne Änderung weiter.

Was sofort seltsam aussah, war das erste jj status:

The working copy has no changes.
Working copy  (@) : qpvuntsm 230dd059 (empty) (no description set)
Parent commit (@-): mzvwutvl a1b2c3d4 main | Initial commit

Es ist bereits ein Commit ausgecheckt, und er ist leer. Von Git kommend sieht ein “leerer Commit ohne Nachricht”, der an der Spitze sitzt, wie ein Fehlerzustand aus. Ist er nicht, es ist die Arbeitskopie selbst, immer als echter Commit dargestellt. Diese eine Idee reicht aus, um neu zu organisieren, wie sich der Rest des Tools liest, und sie ist das ganze Thema des nächsten Beitrags.