Ich sehe eine Zukunft in jj

 (steveklabnik.com)
12 Punkte von GN⁺ 2025-10-24 | 2 Kommentare | Auf WhatsApp teilen
  • Das neue Versionsverwaltungssystem jj ist ein in Rust geschriebenes Projekt, das die Grenzen von Git ausgleicht und sich schrittweise einführen lässt
  • Der Autor bewertet jj auf Grundlage seiner früheren Erfahrung mit der Analyse des Wachstumspotenzials von Rust als ähnlich vielversprechend in Bezug auf Market Fit, spezialisiertes Team und Nutzerbasis
  • jj ist mit Git-Repositories kompatibel und bietet zugleich einen einfacheren Workflow, was es besonders für Entwickler zugänglicher macht, die mit der internen Struktur von Git nicht vertraut sind
  • Die tatsächliche Nutzung breitet sich bereits bei Google und Oxide aus, und es bildet sich eine leidenschaftliche Community mit einem engagierten Entwicklungsteam
  • Der Autor schließt sich ERSC an, das eine auf jj basierende Kollaborationsplattform entwickelt, und plant, das Wachstum des jj-Ökosystems wie in den frühen Tagen von Rust selbst mit voranzutreiben

Warum ich mich für Rust entschieden habe

  • Der Autor wurde an Weihnachten 2012 auf Hacker News durch die Meldung “Rust 0.5 released” auf die Sprache aufmerksam
    • Damals war er Ruby-on-Rails-Entwickler, hatte aber schon seit dem Studium Interesse an Compilern und Systemprogrammierung
  • Bei der Einschätzung der Erfolgsaussichten von Rust berücksichtigte er drei Faktoren: Market Fit, Entwicklungsteam und Nutzerbasis
    • Es gab keine vertrauenswürdige Sprache, die C/C++ ersetzen konnte, und Rust präsentierte mit Speichersicherheit ohne Garbage Collection einen innovativen Ansatz
    • Da Mozilla Rust unterstützte und plante, es in Firefox einzusetzen, hielt er die Chancen für hoch, dass eine echte praktische Nutzungsbasis entstehen würde
  • Auch die freundliche und kooperative Atmosphäre der Rust-Community war ein wichtiger Reizfaktor
    • Später schrieb der Autor das Tutorial „Rust for Rubyists“ und wurde Mitautor der offiziellen Dokumentation

Das Auftauchen von jj

  • jj (Jujutsu) ist keine Programmiersprache, sondern ein neues Versionsverwaltungssystem (VCS), das in Rust implementiert ist
    • Es ist mit Git kompatibel und kann schrittweise eingeführt werden, während bestehende Repositories unverändert weiterverwendet werden
  • Der Autor begann, jj auf Empfehlung des Entwicklers Rain zu erkunden, dessen technischer Geschmack dem seinen ähnelt
    • Rain kommt aus dem Source-Control-Team von Meta, weshalb ihre Empfehlung als vertrauenswürdiges Signal wahrgenommen wurde
  • Am Wochenende experimentierte er selbst mit jj und begann ein Tutorial-Projekt zu schreiben
    • Wie schon beim Lernen von Rust ordnete er seine Gedanken, indem er beim Schreiben die Konzepte ausarbeitete
    • Das Tutorial erhielt in der Community letztlich eine positive Resonanz

Ausblick für jj

  • Der Autor erkennt in jj ein Wachstumsmuster, das den frühen Jahren von Rust ähnelt
    • Market Fit, Teamstärke und Potenzial für Nutzerverbreitung bewertet er allesamt positiv
  • In Sachen Market Fit hat Git zwar eine absolute Vormachtstellung, doch jj kann Git-Repositories direkt verarbeiten und erlaubt dadurch eine teilweise Einführung
    • Auch innerhalb von Oxide verbreitete sich die Nutzung ausgehend von Rain so weit, dass sogar ein eigener Kanal entstand
  • Auch innerhalb von Google wird jj verwendet, was als ähnliches Signal gedeutet wird wie damals die Einführung von Rust bei Mozilla
    • Selbst in Googles großem Monorepo (auf dem Piper-Backend basierend) nutzen einige Projekte jj, was als social proof wirkt
  • Es gibt zwar eine Lernkurve, doch für Nutzer, die mit der internen Struktur von Git nicht vertraut sind, bietet jj eher eine intuitivere und einfachere Bedienung
    • Je mehr jemand Git-Experte ist, desto stärker ist die Anpassung an neue Konzepte erforderlich; allgemeine Entwickler gewöhnen sich dagegen schnell daran
  • Die jj-Community wächst in einer leidenschaftlichen und freundlichen Atmosphäre, die an die frühe Rust-Community erinnert

Das jj-Team und die Community

  • Der Gründer Martin widmet sich seit langer Zeit der Entwicklung von jj und hat das Projekt kürzlich von einem privaten Konto in ein offizielles Organisationskonto überführt und die Governance geordnet
  • Die Teammitglieder sind erfahrene Spezialisten für die Entwicklung von Source-Control-Werkzeugen und zeigen Stärken bei technischer Ausrichtung und Qualitätsmanagement
  • Die Community wächst durch aktives Feedback und Zusammenarbeit schnell und reproduziert die positive Energie der frühen Rust-Community

Neue Herausforderung: Wechsel zu ERSC

  • Der Autor hat entschieden, Oxide zu verlassen und sich dem Startup ERSC anzuschließen, das eine auf jj basierende Kollaborationsplattform entwickelt
    • Oxide war ein großartiger Arbeitsplatz, doch der Wunsch, tiefer am jj-Ökosystem mitzuwirken, war der entscheidende Faktor
  • ERSC plant, auf jj eine Plattform für Entwicklerkollaboration aufzubauen, und erklärt diese frühe Phase mit dem Hinweis darauf, dass GitHub einst unter dem Firmennamen Logical Awesome startete
  • Der Autor will seine Arbeit bei Oxide abschließen, sich dann eine Pause gönnen und sich anschließend ganz auf Aktivitäten in der jj-Community und die Fertigstellung des Tutorials konzentrieren
    • Er kündigt mehr Aktivität auf Discord, eine Blogserie und weitere Community-Beiträge an
  • Er bewertet 2025 als neuen Wendepunkt und drückt seine Dankbarkeit aus, sich einem Projekt widmen zu können, für das er echte Leidenschaft empfindet

Fazit

  • Der Autor ist überzeugt, dass jj das Potenzial hat, den Wachstumspfad von Rust nachzuzeichnen
    • Die Kompatibilität mit Git, die schrittweise Einführung, ein engagiertes Team und eine aktive Community sind seine Begründung
  • jj ist mehr als nur ein Werkzeug und zeigt das Potenzial, sich zu einer innovativen Plattform für die Art und Weise der Entwicklerkollaboration weiterzuentwickeln
  • Die Reise des Autors, die mit Rust begann, setzt sich nun mit jj in einem neuen Kapitel fort

Verwandte Beiträge

2 Kommentare

 
tujuc 2025-10-24

Das ist schon mehrmals aufgekommen, also sollte ich es mir wohl mal ansehen.
 
GN⁺ 2025-10-24
Hacker-News-Kommentare

  • Ich habe jj etwa zweimal ernsthaft ausprobiert. Das Konzept von first-class conflicts ist cool, aber in der Praxis muss man viel häufiger stagen/committen als Konflikte auflösen. Da ich von magit komme, fühlten sich die Funktionen zum Aufteilen und Auswählen von Hunks in jj sehr umständlich an. Ich rebase häufig, daher hatte ich mit den Rebase-Kurzbefehlen von magit die meisten Vorteile von jj bereits. Für Leute wie mich müsste jj die Hunk-Auswahl-UX deutlich verbessern, um magit zu schlagen

    • Der Kern bei jj ist, nicht in staging oder commits zu denken. Alles ist eine Änderung (change), und man sollte so denken, dass man einen Elternknoten oder weiter entfernten Vorfahren als Bookmark setzt, darin squasht oder das Bookmark zur nächsten Änderung verschiebt
    • Ich rebase auch oft, aber die zu meinungsstarke Philosophie der Versionsverwaltung von jj gefällt mir nicht. Besonders für Anfänger halte ich es nicht für hilfreich, die interne Struktur zu stark zu verbergen
    • Mich würde interessieren, wie genau die Hunk-Auswahl-UX von magit aussieht. Sie schien mir nicht so anders zu sein als die von jj. Ich habe lange GitUp(gitup.co) genutzt, und die UX von jj wirkt zwar nicht völlig natürlich, aber das scheint mir etwas zu sein, das sich mit angepassten Shortcuts lösen lässt
    • Wenn man versteht, warum eine gute UX auf Git wichtig ist, versteht man bereits 95 % der Philosophie von jj
    • Man kann in jj auch den git index verwenden. Man darf nur keine jj-Befehle nutzen, die git_head ändern. Ich habe mir dafür einen Alias gebaut, der aus staged Änderungen committet (config.toml-Beispiel)

  • Jedes Mal, wenn ich eine Alternative zu Git sehe, verspüre ich ein wenig ludditische Gefühle. Es gibt schon zu viele Sprachen, Frameworks und Tools. Wenigstens beim VCS bin ich froh, dass es mit Git eine nahezu universelle Lösung gibt. jj mag Probleme lösen, aber wenn man die Belastung bedenkt, dass die Branche beide Systeme unterstützen müsste, scheint mir das kein Nettogewinn zu sein

    • Mich nervt die schwache UI von Git so sehr, dass ich hoffe, es wird ersetzt. Ich hätte gern ein neues Tool, das die Konzepte von Git besser erklärt
    • jj ist eine Option, die einzelne Entwickler wählen können. Ein jj-Repo ist eine Obermenge eines Git-Repos, daher gehen bestehende Tools nicht kaputt
    • Ich habe früher in einer Firma gearbeitet, die svn nutzte, und wir haben zuerst Git über git-svn verwendet. jj scheint einen ähnlichen Ansatz zu verfolgen. Auch ohne jj laufen bestehende CI-Systeme und Tools weiter
    • Git ist ein Produktivitätshemmnis, und im Zeitalter agentenbasierten Codings ist das ein noch größeres Problem. Ich finde jj nicht innovativ genug. Stattdessen bräuchten wir ein neues VCS, das Änderungen atomar (atomic) verfolgt. In so einer Struktur würde das Branch-Konzept verschwinden, und der Zustand eines Repos ließe sich aus Plänen (plans) und Atomen (atoms) zusammensetzen. Der Umstieg auf so ein System wäre allerdings eine enorme Herausforderung
    • So wie nach rcs, cvs und svn git kam, wird auch git irgendwann durch etwas Besseres ersetzt werden

  • Ich habe jj ausprobiert, bin aber an Sublime Merge gewöhnt. Wenn man Versionsverwaltung über die CLI macht, muss man viel wiederholt tippen und verliert leicht den Überblick über den Zustand. In einer GUI ist der Zustand immer sichtbar, und per Klick kann man einen Diff öffnen oder eine Commit-Nachricht eingeben. Hunks per Tastatur auszuwählen möchte ich nie wieder machen. SM ist wirklich angenehm. Es wäre schön, wenn die jj-GUI besser würde oder jj in SM integriert würde

  • Die eigentliche Nachricht ist, dass Leute angefangen haben, Dinge wie „jjhub“ zu bauen (ersc.io)

    • Ich denke, „jjhub“ ist ein brauchbarer erster Schritt. Man kann jj bereits mit github verwenden, aber darüber hinaus müsste es etwas wirklich Wertvolles bieten
    • Zur Info, es gibt auch das hier: Blogpost zu Stacking
    • Gerrit passt auch gut zu den Konzepten von jj, und ein RFC zur Unterstützung von Jujutsu change IDs wurde angenommen
    • Der Name jjhub ist ziemlich cool
    • Ich hoffe wirklich, dass es Erfolg hat. Es ist Zeit für eine echte Alternative zu Github

  • Man hört, dass jj sich intern bei Google verbreitet, aber Google neigt dazu, seine internen VCS regelmäßig auszutauschen. Innerhalb von sieben Jahren ging es von einem git wrapper über eine erweiterte mercurial-Version bis jetzt zu jj

    • Tatsächlich haben die meisten internen Tools bei Google eine kurze Lebensdauer. Trotzdem ist jj innovativ, weil es die Identität (identity) einer Änderung beibehält. In git wird ein Commit nach einem Rebase oder Amend zu einem völlig anderen Commit, aber in jj wird er weiter als dieselbe Änderung verfolgt. Allerdings wird jj am Ende wahrscheinlich weiterhin git als Storage-Backend verwenden
    • Ich hoffe, jj bleibt bestehen. Ich möchte bei der Arbeit und zu Hause denselben Workflow nutzen. Es ist viel schneller als mercurial
    • Diesmal scheint auch die Absicht zu sein, den Perforce-Fork mit aufzugeben. Von außen wirkt das nach sehr viel Veränderung
    • Der git wrapper war ursprünglich experimentell, und das auf mercurial basierende System wurde fast zehn Jahre lang beibehalten

  • Ich frage mich, ob jj mit großen Binärdateien besser umgehen kann als git. In der Spieleentwicklung ist Perforce weiterhin der König. Git reicht selbst mit LFS nicht aus

    • Die Binärdatei-Unterstützung von Perforce ist faktisch dasselbe wie Git LFS. Der Unterschied ist eher, ob es Enterprise-Support gibt
    • jj nutzt git als Repository und unterstützt LFS nicht, daher hat es in diesem Punkt dieselben Einschränkungen wie git
    • Im Moment gibt es hier keine besonderen Verbesserungen, aber man ist sich dieses Bereichs bewusst, und möglicherweise ändert sich das künftig

  • Ich habe etwa einen Tag lang das Jujutsu-Tutorial durchgearbeitet und fand es ziemlich gut. Trotzdem hatte ich das Gefühl, dass ein Puzzlestück fehlt. Zum Beispiel habe ich mich gefragt, ob change IDs beim Erstellen eines PR auf GitHub tatsächlich hilfreich sind. Wahrscheinlich entfalten sie ihren wirklichen Wert nur mit dem internen Piper-Backend von Google. Ich bin gespannt auf die Pläne von ERSC. Persönlich hätte ich gern einen verteilten Workflow mit eingebautem Offline-Code-Review

    • Freut mich, dass es dir Spaß gemacht hat :) Auf GitHub gibt es derzeit fast keinen Vorteil durch change IDs. Aber mit Tools wie jj-spr kann man einen Teil der Erfahrung bekommen. Es gab auch einen Tweet, in dem ein GitHub-SVP Interesse an jj zeigte. Außerdem habe ich beads ausprobiert, ein System, das Issues ins Repository legt, und das gefiel mir ziemlich gut
    • Von jj erzeugte Commits enthalten einen change-id-Header, sodass jj-Nutzer auch dann Rebase-Verläufe verfolgen können, wenn GitHub jj nicht kennt. Das lässt sich mit git cat-file -p HEAD prüfen

  • Ich habe jj ein bis zwei Monate in einem privaten Projekt genutzt und bin ziemlich zufrieden. Wenn man allerdings ältere Revisionen bearbeitet, können neu zu .gitignore hinzugefügte Dateien versehentlich mit aufgenommen werden. Davon abgesehen ist es gut. Trotzdem habe ich noch viel mehr Wissen über Git, daher werde ich es langsam auch in der Firma einführen

  • Ich bin dieses Jahr zu einem Sapling/Subversion-Unternehmen gewechselt und habe jj noch nicht benutzt. Trotzdem ist Sapling viel intuitiver, und Commit-Stacks sind leichter zu verstehen als Branches. Ich frage mich allerdings, wie es ohne Unterstützung wie die Review-UI von Meta aussehen würde. Solche Projekte werden definitiv gebraucht

    • Stimmt, Sapling und jj sind Schwesterprojekte in dieselbe Richtung

  • Wie auch immer der Name sein mag, East River Source Control ist wirklich ein großartiger Name