git status kruipt op SSHFS via een VPN: verplaats het werk

Kopieer een bestand van 200 MB en het vliegt. Voer git status uit in dezelfde map en het wachten duurt lang genoeg om je aandacht te verleggen. Die twee waarnemingen spreken elkaar niet tegen, want bulktransport meet doorvoer terwijl Git meet hoeveel kleine bestandssysteemvragen het per seconde kan stellen, en een aangekoppelde externe boom maakt van elke vraag een retourtje. Aan de VPN draaien lost geen verkeerd gevormde werklast op.

Waarom status de verkeerde maatstaf is

Git moet over veel bestanden iets weten: welke gewijzigd zijn, welke niet gevolgd worden en of gecachte indexgegevens nog kloppen met wat er op schijf staat. Via SSHFS kan elk van die waarnemingen een netwerkbewerking zijn. De werkeenheid hier is het aantal bestanden, niet de megabytes.

Daarom is de eerste status na een kloon traag, en daarom kunnen latere nog trager zijn in een boom vol build-uitvoer. Het scannen van niet-gevolgde bestanden loopt door mappen waar je misschien niets om geeft, en elke stap is weer een verzoek over de verbinding. Op een pad van 40 ms wordt een boom met een paar duizend vermeldingen een paar duizend retourtjes. Er is geen packet capture nodig om die rekensom te bevestigen.

Een downloadbenchmark vertelt dat de verbinding in orde is; hij zegt niets over de vraag of duizend kleine leesacties vanmiddag af zijn.

Verplaats de werkboom, niet de knoppen

Een lokale kloon zet de werkboom, de index en de Git-bewerkingen op dezelfde machine. Een pull wordt een zichtbare netwerkstap in plaats van elke bestandscontrole.

Dit past wanneer de ontwikkelaar de benodigde bron lokaal kan houden, en dat is meestal het geval. Het scherpt ook de grens tussen commit en uitrol aan, omdat het bewerken van een lokaal bestand niet langer per ongeluk een draaiende externe dienst verandert; de wijziging moet worden gepusht en uitgerold zoals al het andere. De prijs is dat de code op twee plaatsen bestaat, dus beslis welke kopie gezaghebbend is en hoe een hotfix op de server terug in de repository komt. Dat gesprek is goedkoper dan een status-commando dat niemand wil draaien.

Als de werkruimte extern moet blijven, draai Git daar

Soms kan de werkruimte niet verhuizen: de build heeft die omgeving nodig, de gegevens zijn te groot of beleid houdt de bron op de host. Draai Git en de relevante ontwikkeltools dan naast de bestanden, via een goedgekeurde externe shell of een externe-ontwikkelomgeving. De editor kan op de laptop blijven terwijl zijn backend naast de werkboom werkt.

Dure bewerkingen gebeuren dan lokaal op de externe host, en het netwerk draagt editorverkeer in plaats van duizenden stat-aanroepen. Het is dezelfde oplossing als een lokale kloon, uitgedrukt als een uitrolkeuze en niet als een migratie.

Synchronisatie is een werkstroom met eigenaren, geen cache

Een gesynchroniseerde werkruimte kan herhaalde externe leesacties verminderen, maar het is geen transparante cache. Het vereist een eigenaar per wijziging, een regel voor conflicten en overeenstemming over gegenereerde bestanden die beide kanten als hun eigendom beschouwen. Zonder die regels schept de regeling onenigheid in plaats van gemak.

Een tweerichtingssynchronisator zonder die regels levert een ander probleem op dan het opgeloste, meestal een samenvoeging die niemand kan toeschrijven. Vermijd twee Git-processen op één gedeelde werkboom, tenzij je begrijpt hoe ze coördineren.

Stel dan af, en houd SSH redelijk

Als de regeling klopt, veranderen twee instellingen over hoeveel bestanden Git moet vragen: status.showUntrackedFiles en de cache van niet-gevolgde bestanden achter core.untrackedCache. Geen van beide verandert wat elke vraag over 40 ms kost; ze veranderen alleen hoeveel vragen er zijn. Draai pas aan een knop als de retourtjes lokaal zijn.

Meet de tijd van het commando dat je irriteert in plaats van te redeneren vanuit een benchmark die één groot bestand kopieert, en laat ondersteunde SSH-versleuteling met rust. Een verouderd cijfer verkort geen retourtje; het voegt een tweede probleem toe dat het eerste overleeft. De git status-referentie is één lezing waard, want het commando doet veel meer werk dan zijn naam suggereert.