Vývojářský tým Gitu vydal novou verzi 2.55.0. Stejně jako u předchozích vydání se na ní podíleli i lidé z týmu GitLabu, který tradičně po každém vydání publikuje přehled toho nejzajímavějšího. Tohle vydání přináší šest pozoruhodných změn – od dlouho očekávané podpory fsmonitoru na Linuxu přes zjednodušení úprav historie commitů až po další krok v postupné integraci jazyka Rust do jádra Gitu. Pojďme se na jednotlivé novinky podívat podrobněji.

git-history(1) se naučil příkaz fixup

V minulé verzi, Gitu 2.54.0, se poprvé objevil nový nástroj git-history(1), určený pro pohodlnější úpravy historie commitů. Verze 2.55 ho rozšiřuje o další užitečný podpříkaz – fixup.

Situace, kterou tento příkaz řeší, zná asi každý, kdo s Gitem pracuje delší dobu: uděláte nějakou změnu a zjistíte, že vlastně nepatří do nového commitu, ale měla by být součástí nějakého staršího. Klasický postup vyžaduje dva kroky – vytvořit speciální „fixup“ commit a následně ho pomocí interaktivního rebase „autosquashnout“ do cílového commitu:

git commit --fixup=<commit-id>
git rebase -i --autosquash <commit-id>^Code language: HTML, XML (xml)

Tenhle postup funguje, ale je poněkud těžkopádný – hlavně proto, že vyžaduje spuštění interaktivního rebase, byť jen na pozadí. Nový příkaz git history fixup dělá totéž v jednom kroku:

git history fixup <commit-id>Code language: HTML, XML (xml)

Příkaz vezme aktuálně stagované změny a rovnou je zapracuje do zadaného commitu. Příjemným bonusem je, že protože jde o nástroj z rodiny git-history(1), automaticky se aktualizují i všechny ostatní lokální větve, které daný commit obsahují. To je velmi praktické zejména při práci se „stackovanými“ větvemi (tedy větvemi postavenými jedna na druhé) – jakmile opravíte commit někde uprostřed stacku, všechny navazující větve se rovnou přerebasují tak, aby na opravu navazovaly, a vy se nemusíte starat o ruční přerovnávání každé z nich zvlášť.

fsmonitor daemon konečně i pro Linux

Druhá novinka řeší dlouhodobý neduh velkých repozitářů – pomalost příkazu git status. Aby Git zjistil, co se ve vašem pracovním adresáři změnilo, musí v zásadě projít celý strom souborů a porovnat ho se stavem indexu. U malých projektů to nikdo nepozná, ale u rozsáhlých monorepozitářů s desítkami či stovkami tisíc souborů se to dokáže citelně prodloužit.

Řešením je mechanismus zvaný filesystem monitor (core.fsmonitor), který má v Gitu poměrně dlouhou historii. Poprvé se objevil už v lednu 2018 ve verzi 2.16 – tehdy si ale uživatel musel sám zajistit a nakonfigurovat externí nástroj, typicky Watchman od Facebooku. Takový nástroj běžel na pozadí, sledoval změny v souborovém systému a hlásil je Gitu, který si pak mohl udržovat „cachovaný“ stav a nemusel ho při každém git status znovu počítat od nuly.

V dubnu 2022 se nastavení core.fsmonitor změnilo tak, aby přijímalo i booleovskou hodnotu. Pokud ji nastavíte na true, Git použije svůj vlastní vestavěný daemon a žádný externí nástroj už není potřeba. Tahle vestavěná varianta ale dlouho fungovala jen na Windows a macOS – podpora pro Linux chyběla.

To se mění právě v Gitu 2.55, kde podpora pro Linux konečně přibyla. Implementace využívá mechanismus jádra inotify, nikoliv alternativní fanotify – ten by sice teoreticky mohl být efektivnější, ale vyžaduje zvýšená oprávnění, což by komplikovalo běžné použití. Řešení s inotify má jednu drobnou daň: fsmonitor musí nasadit sledovací „watcher“ na úplně každý adresář v repozitáři. U opravdu velkých repozitářů s mnoha adresáři se tak můžete snadno dostat na systémový limit fs.inotify.max_user_watches, který bude potřeba ručně zvýšit, aby fsmonitor fungoval spolehlivě.

git push do skupiny vzdálených repozitářů

Třetí novinka se týká práce s více vzdálenými repozitáři najednou. Git už nějakou dobu umožňuje nakonfigurovat tzv. skupinu remotes a stahovat z nich vše jedním příkazem git fetch. Konfigurace vypadá takto:

git config set remotes.forks "origin upstream"Code language: JavaScript (javascript)

Jakmile je skupina nastavená, stačí zavolat:

git fetch forks

a Git stáhne novinky postupně ze všech remotes uvedených ve skupině. Hodí se to typicky ve chvíli, kdy chcete mít přehled o změnách jak v původním (upstream) repozitáři, tak ve svém forku, aniž byste museli psát dva samostatné příkazy.

Příkaz git push ale tuhle možnost doteď neměl – odeslat změny bylo nutné do každého remote zvlášť. Git 2.55 tuhle nesrovnalost odstraňuje a git push teď umí pracovat se skupinami stejně jako git fetch. Pokud tedy chcete odeslat větev main do všech remotes ve skupině forks, stačí napsat:

git push forks main

Git přitom každý remote zpracuje samostatně a respektuje jeho individuální nastavení – tedy případné mapování remote.<name>.push nebo nastavení zrcadlení (mirror). Jde tedy o čistě pohodlovou funkci, která nijak nemění chování pushe k jednotlivým remotes, jen ho zjednodušuje, pokud pravidelně pracujete s více vzdálenými repozitáři současně.

Omezení šířky grafu u git log --graph

Čtvrtá změna se týká vizuálního zobrazení historie commitů. Volba --graph u příkazu git log kreslí do terminálu ASCII reprezentaci větvení a slučování commitů – ty známé svislé čáry a hvězdičky, díky kterým je vidět, jak se historie vyvíjela. Problém nastává v repozitářích s velkým počtem aktivních přispěvatelů, kde tento graf umí narůst do pořádné šířky.

Autoři článku to demonstrují na repozitáři samotného Gitu: stačí pouhých 30 posledních commitů a graf se rozšíří na devět paralelních „pruhů“ (lanes). Důvodem je, že každý pruh pokračuje dolů až k tomu commitu, odkud byla daná větev vytvořena – a s každou další souběžně vyvíjenou větví přibývá další pruh. Výsledkem je, že samotný text commit zprávy je vytlačen daleko doprava, graf se stává nepřehledným a na užší obrazovce terminálu se prostě nevejde.

Git 2.55 na to reaguje novou volbou --graph-lane-limit=<n>, která omezí maximální počet zobrazených pruhů. Jakmile graf přesáhne zadaný limit, přebytečné pruhy se nahradí symbolem ~, takže je na první pohled jasné, že se jedná o zkrácené (oříznuté) zobrazení, a ne o chybu:

git log --graph --graph-lane-limit=5

Výchozí hodnota limitu je 0, což znamená „bez omezení“ – stejné chování jako dosud. Nulové i záporné hodnoty se přitom interpretují stejně, podobně jako je to zvykem u volby --max-parents. Volba navíc dává smysl pouze v kombinaci s --graph – samostatně nic nedělá.

Vývoj Rustu v kódu Gitu

Pátá kapitola se týká dlouhodobého a stále nedokončeného projektu – postupné integrace jazyka Rust do jádra Gitu, který je tradičně psaný v C. Vývoj probíhá postupně, vydání po vydání:

• Git 2.49 (březen 2025): do repozitáře přibyl vůbec první Rust kód – šlo o tzv. bindings, které umožňují Rustu volat funkce z knihovny libgit. Tento kód ale zatím žádný z binárních souborů Gitu reálně nepoužíval, šlo spíš o přípravu půdy.
• Git 2.52 (listopad 2025): přišel první produkční Rust kód – konkrétně implementace subsystému varint. Tento kód se kompiloval volitelně: pokud byl k dispozici Rust kompilátor, použila se Rust verze, jinak Git transparentně spadl zpět na původní implementaci v C. Šlo tak o jakýsi zkušební balonek, aby si distributoři mohli připravit nástroje na dobu, kdy bude Rust v Gitu povinný.
• Git 2.54 (letošní rok): přibyl Rust datový typ ObjectID, a to v rámci širší práce na interoperabilitě mezi hashovacími algoritmy SHA-1 a SHA-256.

Až do téhle chvíle platilo, že oba podporované build systémy, Make i Meson, v případě chybějícího Rust kompilátoru elegantně spadly zpět na C implementaci, takže Rust byl čistě volitelný. Verze 2.55 tohle mění: pokud Git sestavujete ze zdrojových kódů, je Rust kompilátor nově vyžadován, pokud ho výslovně nevypnete v konfiguraci build systému.

Je důležité zdůraznit, že tahle změna se týká výhradně lidí, kteří si Git sami kompilují ze zdrojového kódu – běžné koncové uživatele, kteří používají hotové balíčky z distribucí nebo instalátory, se nijak nedotkne. Pokud kompilujete a Rust při sestavení vypnout chcete, stačí použít jednu z následujících voleb:

# Meson
meson configure -Drust=disabled

# Makefile
make NO_RUST=YesPleaseCode language: PHP (php)

Integrace Rustu do Gitu je dlouhodobý, mnoharočetný projekt celé komunity a nedá se připsat jedinému člověku. Mezi nejvýraznější přispěvatele patří brian m. carlson, Patrick Steinhardt, Ezekiel Newren a Calvin Wan.

Rychlejší git grep a git cherry v částečných klonech

Poslední novinka se týká výkonu při práci s tzv. partial clone (částečným klonem). Jde o funkci Gitu, díky které lze při klonování repozitáře vyfiltrovat, co se vlastně ze serveru stáhne. Typickým příkladem je vynechání obsahu souborů (blobů):

git clone --filter=blob:none <remote>Code language: HTML, XML (xml)

Takový klon je výrazně rychlejší, protože se nestahuje obsah žádného souboru – jen metadata o stromu adresářů a commitech. Cenou za to je, že kdykoliv pak Git potřebuje obsah konkrétního souboru, musí si chybějící blob dotáhnout ze serveru dodatečně, na vyžádání. A některé příkazy mohou potřebovat hodně chybějících blobů najednou.

Typickým příkladem je git grep, který prohledává přímo obsah souborů. Pokud byste chtěli najít výskyt slova „TODO“ napříč historií, sto commitů zpátky:

git grep TODO HEAD~100

Git si nejprve potřebuje rozbalit příslušný commit a strom k němu, a pak zjistí, že řada blobů, na které tento strom odkazuje, ještě není lokálně stažená. Až doteď se každý chybějící blob stahoval samostatně, jeden po druhém – to znamenalo desítky až stovky samostatných síťových požadavků a zbytečně pomalý běh příkazu.

Git 2.55 tohle chování zlepšuje: stahování chybějících blobů se nově seskupuje (batchuje) do jediného vyjednávacího kola se serverem, místo mnoha drobných requestů. Tahle optimalizace se týká jak git grep, tak git cherry, který funguje na podobném principu – porovnává obsah commitů mezi dvěma větvemi.

Shrnutí

Git 2.55.0 tak přináší kombinaci praktických vylepšení pro každodenní práci (zjednodušený fixup commitů, push do skupin remotes, čitelnější graf historie), výkonnostních oprav pro náročnější scénáře (fsmonitor na Linuxu, rychlejší grep a cherry v partial clones) i důležitý interní milník v podobě povinného Rust kompilátoru při sestavování ze zdrojů. Žádná z těchto změn nevyžaduje od běžného uživatele zvláštní akci – stačí na novou verzi aktualizovat a nové možnosti jsou k dispozici.

Kompletní seznam změn najdete v oficiálním oznámení vydání na Git mailing listu, GitLab pak na svém blogu pravidelně publikuje podobné přehledy ke každému novému vydání Gitu.

Zdroj: GitLab Blog – What’s new in Git 2.55.0?