Termín breaking changu nestanoví ten, kdo ho píše
Git přechází na SHA-256. Neexperimentální podpora je v něm od verze 2.42, tedy od roku 2023. Výchozím nastavením se stane až v Gitu 3.0, který přijde po dvou LTS verzích 2.98 a 2.99.
Ta prodleva není o kódu. Kód je hotový tři roky. Datum drží ekosystém, ne implementace. Git svůj objektový formát nečte sám: čtou ho libgit2, JGit, Gitoxide a hlavně hostingové služby. Repozitář, který jeden z nich neumí otevřít, není repozitář.
Co se ve trojce skutečně mění
Dvě věci na úrovni formátu a jedna na úrovni buildu.
SHA-1 se mění na SHA-256. Hash není detail, je to identita každého objektu — commitu, treeu, blobu. SHA-1 je dlouho považovaný za slabý a teoreticky dovoluje nepozorovaně podvrhnout historii. Změna hashe znamená, že se přepíše identifikátor všeho v repozitáři.
Refy se mění na reftable. Dnes leží každý ref jako samostatný soubor pod .git/refs/. U repozitáře s osmi sty tisíci refy, což je případ Androidu, se z toho stane adresář, ve kterém je samotné vyhledání drahé. Reftable je jeden binární soubor navržený na kompaktnost i rychlý přístup. Uživatel z toho neuvidí nic kromě toho, že příkazy přestanou být pomalé.
Třetí věc je build: Rust se stává povinným, což vyřadí platformy, které pro něj nemají toolchain.
Za pozornost stojí, jak různě velké to jsou zásahy navenek. Reftable změní vnitřní uspořádání a nikdo mimo Git ho nemusí umět, protože co Git jednou zapsal, jen Git zpátky čte. SHA-256 změní hodnotu, kterou si mezi sebou posílají všechny nástroje v ekosystému. Proto se o jedné z nich nediskutuje a o druhé roky.
Rozhodovalo, kdo je připravený, ne co je hotové
Sekvence v článku je poučná. Verze se nepojmenovala trojkou proto, že by byl formát dozrálý. Pojmenovala se tak poté, co se ověřilo, že downstream projekty připravené jsou. A i tak zůstala nejistota u GitHubu, protože vydat Git, který vyrábí repozitáře nekompatibilní s největším hostingem, je pro uživatele horší než nevydat nic.
Z toho plyne obecná forma, která se hodí i mimo Git. Když je tvůj datový formát čtený implementacemi, které nevlastníš, přestal být termín změny tvým rozhodnutím a stal se koordinačním problémem. Nástroje, které na to Git použil, jsou přitom ty samé, co se hodí kdekoli: víceletý předběžný ohlas, neutrální verze s podporou obou formátů dávno před přepnutím defaultu, LTS mezikroky, a hlavní verze jako čitelný signál, že se něco láme.
Existující podpora není připravenost. Připravenost je, když formát umí přečíst i ten, kdo tvůj release neplánuje.
Co si z toho odnést
Rozliš ve vlastních formátech dvě kategorie. Interní uspořádání, které čteš jen ty, měň kdy chceš — reftable je tenhle případ. Hodnoty, které vystupují na rozhraní a posílají si je mezi sebou cizí nástroje, jsou závazek a jejich změna se datuje podle nejpomalejší nezávislé implementace.
Pokud takovou změnu čeká, vyplatí se ji postavit v pořadí, které Git použil. Nejdřív umět obojí a nechat to volitelné. Pak roky čekat a dívat se, kdo dojel. Pak přepnout default a to viditelně, na hranici hlavní verze.
A poslední věc, která z toho vyplývá pro plánování: dokud existuje jeden účastník ekosystému, bez kterého je výsledek pro uživatele nepoužitelný, není tvůj termín termínem. Je to odhad, kdy dorazí on.