L'ordre git status s'arrossega per SSHFS sobre una VPN: mou la feina

Copieu un fitxer de 200 MB i vola. Executeu git status al mateix directori i l'espera és prou llarga per canviar de context. Aquestes dues observacions no són contradictòries, perquè la transferència massiva mesura el cabal mentre que Git mesura quantes preguntes petites al sistema de fitxers pot fer per segon, i un arbre remot muntat converteix cada pregunta en un viatge d'anada i tornada. Ajustar la VPN no arreglarà una càrrega de treball mal formada.

Per què status és el punt de referència equivocat

Git ha d'aprendre sobre molts fitxers: quins estan modificats, quins no estan seguits i si les dades d'índex a la memòria cau encara coincideixen amb el que hi ha al disc. Sobre SSHFS cadascuna d'aquestes observacions pot ser una operació de xarxa. La unitat de feina aquí és el nombre de fitxers, no els megabytes.

Per això el primer status després d'un clon és lent, i per això els següents poden ser encara més lents en un arbre ple de sortida de compilació. L'escaneig de no seguits recorre directoris que potser no t'importen, i cada passa és una altra petició a través de l'enllaç. En un camí de 40 ms un arbre amb uns quants milers d'entrades es converteix en uns quants milers de viatges. No cal cap captura de paquets per confirmar aquesta aritmètica.

Una prova de descàrrega et diu que l'enllaç va bé; no diu res sobre si mil lectures petites acabaran aquesta tarda.

Mou l'arbre de treball, no els botons d'ajust

Un clon local posa l'arbre de treball, l'índex i les operacions de Git a la mateixa màquina. Un pull es converteix en un pas de xarxa visible en lloc de ser-ho cada comprovació de fitxer.

Això encaixa sempre que el desenvolupador pugui tenir el codi font necessari en local, que és la majoria de les vegades. També afina la frontera entre el commit i el desplegament, perquè editar un fitxer local ja no canvia per accident un servei remot en funcionament; el canvi s'ha d'enviar i desplegar com qualsevol altra cosa. La contrapartida és que el codi existeix en dos llocs, així que decidiu quina còpia és l'autoritat i com torna una correcció urgent del servidor al repositori. Aquesta conversa és més barata que una ordre status que ningú vol executar.

Si l'espai de treball ha de quedar remot, executa Git allà

De vegades l'espai de treball no es pot moure: la compilació necessita aquell entorn, les dades són massa grans o la política manté el codi font a l'amfitrió. Llavors executeu Git i les eines de desenvolupament rellevants al costat dels fitxers, mitjançant un shell remot aprovat o un entorn de desenvolupament remot. L'editor pot quedar-se a l'ordinador portàtil mentre el seu backend treballa al costat de l'arbre de treball.

Les operacions cares passen llavors en local a l'amfitrió remot, i la xarxa transporta el trànsit de l'editor en lloc de milers de crides stat. És la mateixa solució que un clon local, expressada com una decisió de desplegament i no com una migració.

La sincronització és un flux de treball amb propietaris, no una memòria cau

Un espai de treball sincronitzat pot retallar lectures remotes repetides, però no és una memòria cau transparent. Necessita un propietari per a cada canvi, una regla per als conflictes i un acord sobre els fitxers generats que ambdues bandes creuen posseir. Sense aquestes regles, l'arranjament crea desacord en lloc de comoditat.

Un sincronitzador bidireccional sense elles produeix un problema diferent del que va resoldre, normalment una fusió que ningú no pot atribuir. Eviteu executar dos processos de Git sobre un arbre de treball compartit si no enteneu com es coordinen.

Després ajusta, i mantén SSH assenyat

Quan l'arranjament és correcte, dos paràmetres canvien sobre quants fitxers ha de preguntar Git: status.showUntrackedFiles i la memòria cau de no seguits darrere de core.untrackedCache. Cap dels dos canvia el cost de cada pregunta a través de 40 ms; només canvien quantes preguntes hi ha. Gireu un botó només quan els viatges siguin locals.

Mesureu el temps de l'ordre que us empipa en lloc de raonar a partir d'una prova que copia un fitxer gran, i deixeu en pau el xifratge SSH suportat. Un xifrat obsolet no escurça un viatge d'anada i tornada; afegeix un segon problema que sobreviu al primer. La referència de git status val una lectura, perquè l'ordre fa molta més feina del que el seu nom suggereix.