Zusammenfassung

Eine neue Adresse verändert den Stadtplan

Für eine unveränderte Datei lässt sich ein neuer Hash berechnen. Bei einem Git-Blob ist das der einfache Fall. Bäume enthalten jedoch die Namen ihrer Dateien und Unterbäume. Commits enthalten den Namen ihres Baums und ihrer Eltern-Commits; Tags können weitere Objekte benennen. Der offizielle Entwurf beschreibt die Folge: Ändert sich ein referenzierter Name, ändern sich die Bytes des referenzierenden Objekts. Dessen Name muss ebenfalls neu berechnet werden. Die Kette läuft durch eine verknüpfte Versionsgeschichte. Ein neues Verfahren für die Beschilderung verlangt den Umbau des Stadtplans.

Die alten SHA-1-Namen standen längst in vorhandenen Repositories, auf Servern und in Software, die Git-Daten verarbeitet. Wer einen Gegenstand unter zwei Namen wiedererkennen will, benötigt eine verlässliche Zuordnung. Eine Hashfunktion kann aus Inhalt einen Namen berechnen. Sie liefert keine automatische Übersetzung für bereits vernetzte Bestände.

Deshalb sah der Plan von 2018 eine bidirektionale Namenstabelle vor. Repositories sollten einzeln umgestellt werden und weiterhin mit SHA-1-Servern sprechen können. Das Dokument unterschied Umsetzungsstufen und nahm neue Protokollunterstützung zunächst aus. Es war ein Bauplan für eine Brücke, keine Abnahme ihrer Tragfähigkeit.

Der Schalter erschien vor dem Verkehr

Das git-init-Handbuch von Git 2.29.0 führte 2020 --object-format=sha256 auf. Direkt daneben stand die Warnung: experimentell, für Tests gedacht, im Allgemeinen keine gemeinsame Arbeit mit SHA-1-Repositories. Einen neuen lokalen Bestand anzulegen war möglich. Ihn durch die bestehenden Austauschwege zu schicken, war damit noch nicht erledigt.

Im Handbuch von Git 2.54.0 blieb sha1 im Jahr 2026 die Standardeinstellung und sha256 eine Option. Zwischen Repositories der beiden Objektformate bestand laut demselben Handbuch derzeit keine Interoperabilität. Diese Formulierung trennt den Fortschritt bei der lokalen Formatwahl sauber von der offenen Aufgabe beim Datenaustausch.

Gits BreakingChanges-Dokument plant für Git 3.0 SHA-256 als Standard für neue Repositories. Einen Veröffentlichungstermin nennt es nicht. Bibliotheken, Anwendungen und Hostingdienste müssen vorbereitet sein; eine Abschaffung des SHA-1-Objektformats ist noch nicht geplant. Eine neue Voreinstellung verschiebt künftige Gründungen. Sie räumt die alten Archive nicht über Nacht aus.

Das letzte Wort lag nicht beim Algorithmus

Der Entwurf erläuterte die Schwächen von SHA-1 und die SHAttered-Kollision von 2017. SHA-256 zu wählen war eine nachvollziehbare Antwort. Die organisatorische Rechnung blieb: eingebettete Referenzen, entfernte Dienste und abhängige Programme mussten den Wechsel tragen. Die Git-Entwickler konnten die Richtung festlegen, aber nicht jede Gegenstelle gleichzeitig umstellen. So erklärt sich die Spannung zwischen dem genauen Plan von 2018 und der ebenso genauen Warnung von 2026. Bei einem inhaltsadressierten System steckt der Name mitten im Produkt. Ein Beschluss allein verlegt keine Straße.