git status se plazi po SSHFS prek VPN: premaknite delo

Kopirajte datoteko velikosti 200 MB in leti. Zaženite git status v isti mapi in čakanje je dovolj dolgo, da se posvetite čemu drugemu. Ti dve opažanji si ne nasprotujeta, ker množični prenos meri prepustnost, medtem ko Git meri, koliko majhnih vprašanj na datotečni sistem lahko postavi na sekundo, in pripeta oddaljena veja spremeni vsako vprašanje v povratno potovanje. Prilagajanje VPN ne bo popravilo napačno oblikovane obremenitve.

Zakaj je status napačno merilo

Git mora vedeti o mnogih datotekah: katere so spremenjene, katere niso sledene in ali podatki v predpomnilniku indeksa še ustrezajo temu, kar je na disku. Prek SSHFS je lahko vsako od teh opažanj omrežna operacija. Enota dela je tu število datotek, ne megabajti.

Zato je prvi status po klonu počasen in zato so lahko naslednji še počasnejši v drevesu, polnem izhoda gradnje. Pregledovanje nesledenih gre skozi mape, ki vas morda ne zanimajo, in vsak korak je še ena zahteva prek povezave. Na poti 40 ms drevo z nekaj tisoč vnosi postane nekaj tisoč povratnih potovanj. Za potrditev te aritmetike ni potreben zajem paketov.

Preizkus prenosa pravi, da je povezava v redu; ne pove ničesar o tem, ali bo tisoč majhnih branj končanih danes popoldne.

Premaknite delovno drevo, ne gumbov za uglaševanje

Lokalni klon postavi delovno drevo, indeks in operacije Gita na isti stroj. Pull postane viden omrežni korak, namesto da bi bil to vsak pregled datoteke.

To ustreza vsakič, ko lahko razvijalec hrani potrebni vir lokalno, kar je večinoma. Zaostri tudi mejo med commitom in uvajanjem, ker urejanje lokalne datoteke ne spremeni več po naključju delujoče oddaljene storitve; spremembo je treba potisniti in uvesti kot vse drugo. Cena je, da koda obstaja na dveh mestih, zato se odločite, katera kopija je merodajna in kako se nujni popravek na strežniku vrne v shrambo. Ta pogovor je cenejši od ukaza status, ki ga nihče noče zagnati.

Če mora delovni prostor ostati oddaljen, zaženite Git tam

Včasih delovnega prostora ni mogoče premakniti: gradnja potrebuje to okolje, podatki so preveliki ali politika drži vir na gostitelju. Takrat zaženite Git in ustrezna razvojna orodja ob datotekah, prek odobrene oddaljene lupine ali okolja za oddaljeni razvoj. Urejevalnik lahko ostane na prenosniku, medtem ko njegov backend dela ob delovnem drevesu.

Drage operacije se potem zgodijo lokalno na oddaljenem gostitelju, omrežje pa prenaša promet urejevalnika namesto tisočih klicev stat. To je ista poprava kot lokalni klon, izražena kot odločitev o uvajanju in ne kot migracija.

Usklajevanje je delovni tok z lastniki, ne predpomnilnik

Usklajen delovni prostor lahko zmanjša ponavljajoča se oddaljena branja, a ni prosojni predpomnilnik. Potrebuje lastnika vsake spremembe, pravilo za konflikte in dogovor o ustvarjenih datotekah, ki jih obe strani imata za svoje. Brez teh pravil ureditev ustvarja nesoglasje, ne udobja.

Dvosmerni usklajevalnik brez njih ustvari drugačno težavo od tiste, ki jo je rešil, običajno združitev, ki je nihče ne more pripisati. Izogibajte se zagonu dveh procesov Gita na enem skupnem delovnem drevesu, razen če razumete, kako se usklajujeta.

Nato uglasite in ohranite SSH razumen

Ko je ureditev pravilna, dve nastavitvi spremenita, o koliko datotekah se mora Git spraševati: status.showUntrackedFiles in predpomnilnik nesledenih za core.untrackedCache. Nobena ne spremeni, koliko stane vsako vprašanje čez 40 ms; spremenita le, koliko vprašanj je. Gumb obrnite šele, ko so povratna potovanja lokalna.

Izmerite čas ukaza, ki vas jezi, namesto da sklepate iz preizkusa, ki kopira eno veliko datoteko, in pustite podprto šifriranje SSH pri miru. Zastarela šifra ne skrajša povratnega potovanja; doda drugo težavo, ki preživi prvo. Referenca za git status je vredna enega branja, ker ukaz opravi veliko več dela, kot nakazuje ime.