git status kryper på SSHFS över en VPN: flytta arbetet

Kopiera en fil på 200 MB och den flyger. Kör git status i samma katalog och väntan är lång nog att tänka på något annat. De två observationerna motsäger inte varandra, eftersom masstransfer mäter genomströmning medan Git mäter hur många små filsystemsfrågor det kan ställa per sekund, och ett monterat fjärrträd gör varje fråga till en tur och retur. Att trimma VPN:en fixar inte en felformad arbetsbelastning.

Varför status är fel måttstock

Git måste veta om många filer: vilka som är ändrade, vilka som är ospårade och om cachade indexdata fortfarande stämmer med det som ligger på disken. Över SSHFS kan var och en av dessa observationer vara en nätverksoperation. Arbetsenheten här är antalet filer, inte megabyten.

Därför är den första status efter en klon långsam, och därför kan senare vara ännu långsammare i ett träd fullt av byggutdata. Skanning av ospårade filer går genom kataloger du kanske inte bryr dig om, och varje steg är ännu en begäran över länken. På en väg på 40 ms blir ett träd med några tusen poster några tusen turer fram och tillbaka. Ingen paketfångst behövs för att bekräfta den aritmetiken.

Ett nedladdningsmått säger att länken är bra; det säger ingenting om huruvida tusen små läsningar blir klara i eftermiddag.

Flytta arbetsträdet, inte trimknapparna

En lokal klon lägger arbetsträdet, indexet och Git-operationerna på samma maskin. En pull blir ett synligt nätverkssteg i stället för att varje filkontroll blir det.

Detta passar när utvecklaren kan hålla den nödvändiga källan lokalt, vilket oftast är fallet. Det skärper också gränsen mellan commit och utrullning, eftersom redigering av en lokal fil inte längre ändrar en körande fjärrtjänst av misstag; ändringen måste pushas och rullas ut som allt annat. Priset är att koden finns på två ställen, så bestäm vilken kopia som är auktoritativ och hur en hotfix på servern kommer tillbaka i repot. Det samtalet är billigare än ett status-kommando som ingen vill köra.

Om arbetsytan måste vara fjärr, kör Git där

Ibland kan arbetsytan inte flyttas: bygget behöver den miljön, data är för stora eller policy håller källan på värden. Kör då Git och de relevanta utvecklingsverktygen bredvid filerna, via ett godkänt fjärrskal eller en fjärrutvecklingsmiljö. Editorn kan stanna på laptopen medan dess backend arbetar bredvid arbetsträdet.

Dyra operationer sker då lokalt på fjärrvärden, och nätverket bär editortrafik i stället för tusentals stat-anrop. Det är samma åtgärd som en lokal klon, uttryckt som ett utrullningsval och inte en migrering.

Synk är ett arbetsflöde med ägare, inte en cache

En synkroniserad arbetsyta kan minska upprepade fjärrläsningar, men det är inte en transparent cache. Den behöver en ägare för varje ändring, en regel för konflikter och en överenskommelse om genererade filer som båda sidor anser sig äga. Utan dessa regler skapar arrangemanget oenighet i stället för bekvämlighet.

En tvåvägssynkronisering utan dem skapar ett annat problem än det löste, vanligtvis en sammanslagning som ingen kan tillskriva. Undvik att köra två Git-processer mot ett delat arbetsträd om du inte förstår hur de samordnar.

Trimma sedan, och håll SSH vettigt

När arrangemanget är rätt ändrar två inställningar hur många filer Git måste fråga om: status.showUntrackedFiles och cachen för ospårade bakom core.untrackedCache. Ingen av dem ändrar vad varje fråga kostar över 40 ms; de ändrar bara hur många frågor det finns. Vrid på en ratt först när turerna fram och tillbaka är lokala.

Ta tid på kommandot som irriterar dig i stället för att resonera från ett mått som kopierar en stor fil, och lämna stödd SSH-kryptering i fred. En föråldrad chiffer förkortar inte en tur och retur; den lägger till ett andra problem som överlever det första. Git status-referensen är värd en läsning, eftersom kommandot gör långt mer arbete än namnet antyder.