git status krabbar på SSHFS over ein VPN: flytt arbeidet

Kopier ei fil på 200 MB, og ho flyg. Køyr git status i same mappe, og ventinga er lang nok til å tenkje på noko anna. Dei to observasjonane motseier ikkje kvarandre, fordi massetransport måler gjennomstrøyming, medan Git måler kor mange små filsystemspørsmål det kan stille per sekund, og eit montert fjerntre gjer kvart spørsmål til ein rundtur. Å tune VPN-en fiksar ikkje ei arbeidsmengd som er forma feil.

Kvifor status er feil målestokk

Git må vita om mange filer: kva som er endra, kva som er uspora, og om bufra indeksdata framleis stemmer med det som ligg på disken. Over SSHFS kan kvar av desse observasjonane vere ein nettverksoperasjon. Arbeidseininga her er talet på filer, ikkje megabyta.

Difor er den første status etter ein klone treg, og difor kan seinare vere endå tregare i eit tre fullt av byggjeutdata. Skannning av uspora filer går gjennom mapper du kanskje ikkje bryr deg om, og kvart steg er ei ny førespurnad over sambandet. På ein veg på 40 ms blir eit tre med nokre tusen oppføringar til nokre tusen rundturar. Det trengst ingen pakkefangst for å stadfeste den aritmetikken.

Ein nedlastingsmålestokk fortel at sambandet er fint; han seier ingenting om korvidt tusen små lesingar blir ferdige i ettermiddag.

Flytt arbeidstreet, ikkje tune-knappane

Ein lokal klone legg arbeidstreet, indeksen og Git-operasjonane på same maskin. Ein pull blir eit synleg nettverkssteg i staden for at kvar filkontroll blir det.

Dette passar når utviklaren kan halde den naudsynte kjelda lokalt, noko som er det vanlegaste. Det skjerpar òg grensa mellom commit og utrulling, fordi redigering av ei lokal fil ikkje lenger endrar ein køyrande fjern teneste ved eit uhell; endringa må pushast og rullast ut som alt anna. Prisen er at koden finst på to stader, så avgjer kva kopi som er autoritativ og korleis ein hotfix på tenaren kjem tilbake i repoet. Den samtalen er billegare enn ein status-kommando ingen vil køyre.

Viss arbeidsområdet må bli fjernt, køyr Git der

Nokre gonger kan ikkje arbeidsområdet flyttast: bygget treng det miljøet, dataa er for store, eller policy held kjelda på verten. Køyr då Git og dei relevante utviklarverktøya ved sida av filene, gjennom eit godkjent fjernskal eller eit fjernutviklingsmiljø. Editoren kan bli på laptopen medan backend-en jobbar ved sida av arbeidstreet.

Dyre operasjonar skjer då lokalt på fjernverten, og nettverket ber editortrafikk i staden for tusener av stat-kall. Det er same løysing som ein lokal klone, uttrykt som eit utrullingsval og ikkje ei migrering.

Synkronisering er ein arbeidsflyt med eigarar, ikkje ein hurtigbuffer

Eit synkronisert arbeidsområde kan kutte gjentekne fjerne lesingar, men det er ikkje ein gjennomsiktig hurtigbuffer. Det treng ein eigar for kvar endring, ein regel for konfliktar og ein avtale om genererte filer som begge sider meiner dei eig. Utan desse reglane skaper ordninga usemje i staden for bekvemmelegheit.

Ein tovegssynkronisator utan dei skaper eit anna problem enn det han løyste, vanlegvis ei samanslåing ingen kan tilskrive. Unngå å køyre to Git-prosessar mot eitt delt arbeidstre, med mindre du forstår korleis dei koordinerer.

Så tune, og hald SSH fornuftig

Når ordninga er rett, endrar to innstillingar kor mange filer Git må spørje om: status.showUntrackedFiles og hurtigbufferen for uspora bak core.untrackedCache. Ingen av dei endrar kva kvart spørsmål kostar over 40 ms; dei endrar berre kor mange spørsmål det er. Skru på ein knapp først når rundturane er lokale.

Ta tida på kommandoen som irriterer deg i staden for å resonnere frå ein målestokk som kopierer éi stor fil, og lat støtta SSH-kryptering vere. Ein utdatert chiffre forkortar ikkje ein rundtur; han legg til eit andre problem som overlever det første. Git status-referansen er verdt éi lesing, fordi kommandoen gjer langt meir arbeid enn namnet antydar.