git status krabber på SSHFS over en VPN: flytt arbeidet

Kopier en fil på 200 MB, og den flyr. Kjør git status i samme mappe, og ventingen er lang nok til å tenke på noe annet. De to observasjonene motsier ikke hverandre, fordi massetransport måler gjennomstrømning, mens Git måler hvor mange små filsystemspørsmål det kan stille per sekund, og et montert fjerntre gjør hvert spørsmål til en rundtur. Å tune VPN-en fikser ikke en arbeidsmengde som er formet feil.

Hvorfor status er feil målestokk

Git må vite om mange filer: hvilke som er endret, hvilke som er usporede, og om bufrede indeksdata fortsatt stemmer med det som ligger på disken. Over SSHFS kan hver av disse observasjonene være en nettverksoperasjon. Arbeidsenheten her er antall filer, ikke megabytene.

Derfor er den første status etter en klone treg, og derfor kan senere være enda tregere i et tre fullt av byggeutdata. Skannning av usporede filer går gjennom mapper du kanskje ikke bryr deg om, og hvert steg er en ny forespørsel over forbindelsen. På en vei på 40 ms blir et tre med noen tusen oppføringer til noen tusen rundturer. Det trengs ingen pakkefangst for å bekrefte den aritmetikken.

En nedlastingsmålestokk forteller at forbindelsen er fin; den sier ingenting om hvorvidt tusen små lesinger blir ferdige i ettermiddag.

Flytt arbeidstreet, ikke tune-knappene

En lokal klone legger arbeidstreet, indeksen og Git-operasjonene på samme maskin. En pull blir et synlig nettverkssteg i stedet for at hver filkontroll blir det.

Dette passer når utvikleren kan holde den nødvendige kilden lokalt, noe som er det vanligste. Det skjerper også grensen mellom commit og utrulling, fordi redigering av en lokal fil ikke lenger endrer en kjørende fjern tjeneste ved et uhell; endringen må pushes og rulles ut som alt annet. Prisen er at koden finnes på to steder, så bestem hvilken kopi som er autoritativ og hvordan en hotfix på serveren kommer tilbake i repoet. Den samtalen er billigere enn en status-kommando ingen vil kjøre.

Hvis arbeidsområdet må bli fjernt, kjør Git der

Noen ganger kan ikke arbeidsområdet flyttes: bygget trenger det miljøet, dataene er for store, eller policy holder kilden på verten. Kjør da Git og de relevante utviklingsverktøyene ved siden av filene, gjennom et godkjent fjernskall eller et fjernutviklingsmiljø. Editoren kan bli på laptopen mens backend-en jobber ved siden av arbeidstreet.

Dyre operasjoner skjer da lokalt på fjernverten, og nettverket bærer editortrafikk i stedet for tusener av stat-kall. Det er samme løsning som en lokal klone, uttrykt som et utrullingsvalg og ikke en migrering.

Synkronisering er en arbeidsflyt med eiere, ikke en hurtigbuffer

Et synkronisert arbeidsområde kan kutte gjentatte fjerne lesinger, men det er ikke en gjennomsiktig hurtigbuffer. Det trenger en eier for hver endring, en regel for konflikter og en avtale om genererte filer som begge sider mener de eier. Uten disse reglene skaper ordningen uenighet i stedet for bekvemmelighet.

En toveissynkronisator uten dem skaper et annet problem enn det den løste, vanligvis en sammenslåing ingen kan tilskrives. Unngå å kjøre to Git-prosesser mot ett delt arbeidstre, med mindre du forstår hvordan de koordinerer.

Så tune, og hold SSH fornuftig

Når ordningen er riktig, endrer to innstillinger hvor mange filer Git må spørre om: status.showUntrackedFiles og hurtigbufferen for usporede bak core.untrackedCache. Ingen av dem endrer hva hvert spørsmål koster over 40 ms; de endrer bare hvor mange spørsmål det er. Skru på en knapp først når rundturene er lokale.

Ta tiden på kommandoen som irriterer deg i stedet for å resonnere fra en målestokk som kopierer én stor fil, og la støttet SSH-kryptering være. En utdatert chiffre forkorter ikke en rundtur; den legger til et andre problem som overlever det første. Git status-referansen er verdt én lesing, fordi kommandoen gjør langt mer arbeid enn navnet antyder.