git status se plazí na SSHFS přes VPN: přesuňte práci

Zkopírujte soubor o 200 MB a letí. Spusťte git status ve stejném adresáři a čekání je dost dlouhé na to, abyste přepnuli na jinou práci. Ta dvě pozorování si neodporují, protože hromadný přenos měří propustnost, kdežto Git měří, kolik malých dotazů na souborový systém dokáže položit za sekundu, a připojený vzdálený strom mění každý dotaz v obrátku. Ladění VPN neopraví špatně tvarovanou zátěž.

Proč je status špatné měřítko

Git se musí dozvědět o mnoha souborech: které jsou změněné, které nesledované a zda data v keši indexu ještě odpovídají tomu, co leží na disku. Přes SSHFS může být každé z těchto pozorování síťová operace. Jednotkou práce je zde počet souborů, ne megabajty.

Proto je první status po klonu pomalý a proto mohou být další ještě pomalejší ve stromu plném výstupů sestavení. Skenování nesledovaných souborů prochází adresáře, které vás nemusí zajímat, a každý krok je další požadavek přes spojení. Na cestě 40 ms se strom s několika tisíci položkami změní v několik tisíc obrátek. K potvrzení této aritmetiky není potřeba zachytávat pakety.

Test stahování vám řekne, že spojení je v pořádku; nic neříká o tom, zda tisíc malých čtení dnes odpoledne skončí.

Přesuňte pracovní strom, ne knoflíky ladění

Lokální klon umísťuje pracovní strom, index a operace Gitu na stejný stroj. Pull se stane viditelným síťovým krokem, místo aby jím bylo každé ověření souboru.

Hodí se to vždy, když vývojář může mít potřebné zdroje lokálně, což je většinou. Také to zostřuje hranici mezi commitem a nasazením, protože úprava lokálního souboru už omylem nemění běžící vzdálenou službu; změna se musí odeslat a nasadit jako cokoli jiného. Cenou je, že kód existuje na dvou místech, takže rozhodněte, která kopie je závazná a jak se horká oprava na serveru vrátí do repozitáře. Ten rozhovor je levnější než příkaz status, který nikdo nechce spouštět.

Pokud musí pracovní prostor zůstat vzdálený, spouštějte Git tam

Někdy se pracovní prostor přestěhovat nemůže: sestavení potřebuje to prostředí, data jsou příliš velká nebo politika drží zdroje na hostiteli. Pak spouštějte Git a příslušné vývojové nástroje vedle souborů, přes schválený vzdálený shell nebo prostředí vzdáleného vývoje. Editor může zůstat na notebooku, zatímco jeho backend pracuje vedle pracovního stromu.

Drahé operace se pak odehrávají lokálně na vzdáleném hostiteli a síť přenáší provoz editoru místo tisíců volání stat. Je to stejná oprava jako lokální klon, vyjádřená jako volba nasazení, ne jako migrace.

Synchronizace je pracovní postup s vlastníky, ne keš

Synchronizovaný pracovní prostor může omezit opakovaná vzdálená čtení, ale není to průhledná keš. Potřebuje vlastníka každé změny, pravidlo pro konflikty a dohodu o generovaných souborech, které obě strany považují za své. Bez těch pravidel uspořádání vytváří neshodu, ne pohodlí.

Obousměrný synchronizátor bez nich vytváří jiný problém, než jaký řešil, obvykle sloučení, které nikdo nedokáže připsat. Vyhněte se spouštění dvou procesů Gitu nad jedním sdíleným pracovním stromem, pokud nerozumíte tomu, jak se koordinují.

Pak laďte a udržujte SSH rozumné

Když je uspořádání správné, dvě nastavení mění, o kolika souborech se Git musí ptát: status.showUntrackedFiles a keš nesledovaných za core.untrackedCache. Ani jedno nemění cenu každého dotazu přes 40 ms; mění jen to, kolik dotazů existuje. Knoflíkem otáčejte až tehdy, když jsou obrátky lokální.

Změřte čas příkazu, který vás štve, místo abyste usuzovali z testu, který kopíruje jeden velký soubor, a nechte podporované šifrování SSH na pokoji. Zastaralá šifra nezkracuje obrátku; přidává druhý problém, který přežije ten první. Referenční příručka ke git status stojí za jedno přečtení, protože příkaz dělá mnohem víc práce, než jeho název naznačuje.