Gits Weiterentwicklung für die nächsten zehn Jahre

• Git, das von Entwicklerinnen und Entwicklern weltweit genutzt wird, treibt strukturelle Veränderungen voran, um sich auf die kommenden zehn Jahre vorzubereiten. Im Mittelpunkt der wichtigsten Umbauten stehen Sicherheit, Skalierbarkeit und Benutzerfreundlichkeit
• Die auffälligste Veränderung ist der Wechsel von SHA-1 zu SHA-256. Bis 2030 soll die Nutzung von SHA-1 verboten werden, doch die Einführung verzögert sich wegen mangelnder Unterstützung im Ökosystem
• Mit der Einführung von Reftable wird versucht, Hunderte Millionen Referenzen effizient zu verwalten und Einschränkungen des Dateisystems sowie Nebenläufigkeitsprobleme zu lösen
• Zur Verbesserung der Verarbeitung großer Dateien werden Large-object promisors und eine pluggbare Objektdatenbank entwickelt; eine schrittweise Integration in Versionen nach Git 2.50 läuft bereits
• Unter dem Einfluss neuer Versionsverwaltungssysteme wie Jujutsu will Git moderne Workflows durch eine vereinfachte UI und neue Befehle unterstützen

---

Warum Git sich verändern muss

• Seit seiner Veröffentlichung im Jahr 2005 hat sich Git in 20 Jahren zu einem zentralen Werkzeug entwickelt, auf das Millionen von Repositories und unzählige Skripte angewiesen sind
  • Doch durch Veränderungen im Umfeld wie Sicherheitslücken in SHA-1, das Wachstum großer Repositories und die Verbreitung von CI-Pipelines wurden strukturelle Grenzen sichtbar
• Bei SHA-1 wurde 2017 durch den SHAttered-Angriff von CWI und Google die Möglichkeit von Kollisionen nachgewiesen
  • Durch die gestiegene GPU-Rechenleistung ist inzwischen ein Niveau erreicht, auf dem große Organisationen Hash-Kollisionen berechnen können
• Git muss statt einer radikalen Neugestaltung eine schrittweise Evolution wählen und treibt den Wandel bei gleichzeitiger Kompatibilität mit dem bestehenden Ökosystem voran

Umstellung auf SHA-256

• In Git 2.29 (Oktober 2020) wurde SHA-256-Unterstützung hinzugefügt, große Plattformen wie GitHub unterstützen sie jedoch noch nicht
  • Git, Dulwich und Forgejo unterstützen sie vollständig, GitLab, go-git und libgit2 befinden sich bei der Unterstützung noch im experimentellen Stadium
• SHA-1 wird zwar nur zur einfachen Integritätsprüfung verwendet, doch das gesamte Ökosystem — etwa Signaturen, CI und Skripte — arbeitet unter der Annahme von Kollisionsresistenz
• Aufgrund staatlicher und unternehmensinterner Vorgaben muss SHA-1 bis 2030 entfernt werden; in Git 3.0 soll SHA-256 zum Standardwert werden
• Für die Umstellung des Ökosystems wird Nutzerinnen und Nutzern empfohlen, sich durch Tests von Tools und Anfragen nach Forge-Unterstützung zu beteiligen

Einführung von Reftable

• Bisher verwendet Git eine Loose-Reference-Struktur, bei der jede Referenz als separate Datei gespeichert wird
  • In Repositories mit zig Millionen Referenzen ist das ineffizient; außerdem treten Probleme mit Groß-/Kleinschreibung im Dateisystem und Inkonsistenzen bei Nebenläufigkeit auf
• Reftable ist eine tabellenbasierte Struktur auf Basis eines Binärformats, die atomare Updates und eine effiziente Verwaltung von Referenzen ermöglicht
  • Im Fall eines GitLab-Repositories mit 20 Millionen Referenzen musste die bisherige packed-refs-Datei jeweils mit 2 GB neu geschrieben werden
• In Git 3.0 wird Reftable zum Standard-Backend; empfohlen wird, Git-Befehle statt direkter Dateizugriffe zu verwenden

Verbesserungen bei der Verarbeitung großer Dateien

• Git ist beim Komprimieren von Textdateien effizient, bei Änderungen an Binärdateien entsteht jedoch Ineffizienz, weil das gesamte Objekt neu erzeugt werden muss
  • Laut einer GitLab-Analyse entfallen 75 % des Repository-Speicherplatzes auf Binärdateien ab 1 MB
• Die Funktion Large-object promisors speichert große Objekte in einem separaten Remote-Speicher und ermöglicht die Übertragung über ein CDN oder eine S3-API
  • In Git 2.50 bis 2.52 wurde die Protokollimplementierung abgeschlossen; die clientseitige Nutzung ist nun möglich
• Eine pluggbare Objektdatenbank soll ein binärdateispezifisches Speicherformat einführen und inkrementelle Speicherung unterstützen
  • In Git 2.53 wurde eine integrierte Schnittstelle für Objektdatenbanken eingeführt, für 2.54 wird ein Proof of Concept (PoC) erwartet

Verbesserungen an der Benutzeroberfläche

• Git-Befehle stehen seit langem in der Kritik, komplex und inkonsistent zu sein; als Alternative gewinnt das auf Rust basierende Jujutsu (JJ) an Bedeutung
  • Jujutsu bietet automatische Neuplatzierung der Historie, die Behandlung von Konflikten als Daten und einen Ansatz, Commits wie Entwürfe zu behandeln
• Git übernimmt nun einige Vorteile von Jujutsu, ohne bestehende Workflows zu zerstören
  • In Git 2.54 sollen die Befehle git history split und git history reword hinzukommen
  • Künftig sollen weitere Subkommandos zur Bearbeitung der Historie ergänzt werden
• Steinhardt betont, dass Git durch Wettbewerb lernt und dass die Modernisierung der UI und Verbesserungen der Benutzerfreundlichkeit voranschreiten

[GN⁺]

Hacker-News-Kommentare

• Git ist wirklich wunderschöne Software, zeigt aber auch eine Komplexität, die stark auf Programmierer zugeschnitten ist
  Ich habe schon versucht, Menschen außerhalb der Entwicklung Git beizubringen, und sie konnten die subtile Mächtigkeit der Funktionen nicht vollständig nutzen
  Seiten wie Learn Git Branching sind großartige Lernressourcen. So eine UX sollte in die Standarderfahrung von Git einfließen — etwa intuitive Standardwerte und ein schrittweiser Lernablauf
  Heutzutage lässt sich so eine Erfahrung mit Agent-CLIs wie Claude, Codex und OpenCode leicht bereitstellen. Aber wenn Git selbst eine zugänglichere Abstraktion bieten würde, wäre es viel einfacher

  • Das Problem ist nicht, dass Git die Komplexität offenlegt, sondern dass es diese Komplexität durch falsche Terminologie und Konzepte sowie chaotische Dokumentation ausdrückt

• Ich freue mich wirklich auf Git 3.0, bin aber gleichzeitig schon auf Frustration vorbereitet 😅
  jj hat Git-Nutzern sehr geholfen. Es hat gezeigt, dass ein intuitiveres VCS-Frontend möglich ist

  • Je mehr Konkurrenz es gibt, desto besserer Anreiz entsteht für das Ökosystem

• Ich habe bei GitLab Fälle gesehen, in denen eine 2-GB-große packed-refs-Datei alle paar Sekunden neu geschrieben wurde, und ich verstehe einfach nicht, „warum so etwas überhaupt passiert“

  • Und ehrlich gesagt weiß ich auch nicht, ob es irgendeinen Grund gibt, warum Git oder die betreffende Person sich darum kümmern müsste

• Große Dateien extern zu speichern wirkt wie ein Schritt in Richtung eines zentralisierten Modells, widerspricht aber der ursprünglichen Designphilosophie von Git

  • Nicht unbedingt. Das ist nur eine Frage des Adressierungsmodells und der Schnittstelle. Man kann ein zentrales Repository nutzen, aber auch verteilten Storage wie IPFS
  • Stimmt. Git ist ein DVCS, kein allgemeines DVFS. Ich brauchte ein DVFS zum Speichern von Dokumenten und habe deshalb selbst eines gebaut. Es ist einfach, schnell und funktioniert gut für seinen Zweck

• Der Umstieg weg von SHA1 dauert viel zu lange
  Hash-Funktionen hätten von Anfang an mit einer modulareren Struktur entworfen werden sollen

• Ich finde, Git braucht eine Funktion zur Verfolgung von Softwarelizenzen auf Commit-Ebene

  • Ich verstehe nicht ganz, was damit gemeint ist, aber das ist nicht Git's Aufgabe. Git ist nur ein Quellcodeverwaltungssystem, und zusätzliche Funktionen sollten über Erweiterungswerkzeuge wie git-annex umgesetzt werden
  • Git würde durch so eine Funktion eher schlechter. In Commits kann man bereits beliebige Daten speichern, also sollte man die nötigen Metadaten einfach in den Commit packen und mit separaten Tools verarbeiten
  • Man kann dafür Trailer verwenden, wie bei LLM-unterstütztem Code
    Beispiel: Co-Authored-By: Whatever LLM, License: WTFPL