git status arrástrase por SSHFS sobre unha VPN: move o traballo

Copia un ficheiro de 200 MB e voa. Executa git status no mesmo directorio e a espera é abondo longa para cambiar de contexto. Esas dúas observacións non se contradín, porque a transferencia masiva mide o caudal mentres que Git mide cantas preguntas pequenas ao sistema de ficheiros pode facer por segundo, e unha árbore remota montada converte cada pregunta nunha ida e volta. Axustar a VPN non arranxará unha carga de traballo mal formada.

Por que status é a referencia equivocada

Git ten que saber de moitos ficheiros: cales están modificados, cales non están rastrexados e se os datos de índice na caché seguen coincidindo co que hai no disco. Sobre SSHFS cada unha desas observacións pode ser unha operación de rede. A unidade de traballo aquí é o número de ficheiros, non os megabytes.

Por iso o primeiro status tras un clon é lento, e por iso os seguintes poden ser aínda máis lentos nunha árbore chea de saída de compilación. O escaneo dos non rastrexados percorre directorios que quizais non che importen, e cada paso é outra petición pola ligazón. Nun camiño de 40 ms unha árbore con uns miles de entradas convértese en varios miles de idas e voltas. Non fai falta capturar paquetes para confirmar esa aritmética.

Unha proba de descarga diche que a ligazón vai ben; non di nada sobre se mil lecturas pequenas rematarán esta tarde.

Move a árbore de traballo, non os botóns de axuste

Un clon local pon a árbore de traballo, o índice e as operacións de Git na mesma máquina. Un pull pasa a ser un paso de rede visible en lugar de o ser cada comprobación de ficheiro.

Isto encaixa sempre que o desenvolvedor poida ter a fonte necesaria en local, que é a maioría das veces. Tamén afina a fronteira entre o commit e o despregamento, porque editar un ficheiro local xa non cambia por accidente un servizo remoto en execución; o cambio ten que enviarse e despregarse como calquera outra cousa. A contrapartida é que o código existe en dous sitios, así que decide que copia é a autoritativa e como volve ao repositorio unha corrección urxente do servidor. Esa conversa é máis barata que un comando status que ninguén quere executar.

Se o espazo de traballo debe quedar remoto, executa Git alí

Ás veces o espazo de traballo non se pode mover: a compilación necesita ese contorno, os datos son demasiado grandes ou a política mantén a fonte no host. Daquela executa Git e as ferramentas de desenvolvemento pertinentes xunto aos ficheiros, mediante un shell remoto aprobado ou un contorno de desenvolvemento remoto. O editor pode quedar no portátil mentres o seu backend traballa xunto á árbore de traballo.

As operacións caras ocorren entón en local no host remoto, e a rede transporta o tráfico do editor en lugar de miles de chamadas stat. É o mesmo arranxo que un clon local, expresado como unha decisión de despregamento e non como unha migración.

A sincronización é un fluxo de traballo con donos, non unha caché

Un espazo de traballo sincronizado pode recortar lecturas remotas repetidas, pero non é unha caché transparente. Necesita un dono para cada cambio, unha regra para os conflitos e un acordo sobre os ficheiros xerados que ambas as partes cren posuír. Sen esas regras o arranxo crea desacordo en lugar de comodidade.

Un sincronizador bidireccional sen elas produce un problema distinto do que resolveu, normalmente unha fusión que ninguén pode atribuír. Evita executar dous procesos de Git sobre unha árbore de traballo compartida se non entendes como se coordinan.

Logo axusta, e mantén SSH sensato

Cando o arranxo é correcto, dous axustes cambian sobre cantos ficheiros ten que preguntar Git: status.showUntrackedFiles e a caché dos non rastrexados detrás de core.untrackedCache. Ningún cambia o que custa cada pregunta a través de 40 ms; só cambian cantas preguntas hai. Xira un botón só cando as idas e voltas sexan locais.

Mide o tempo do comando que te irrita en lugar de razoar desde unha proba que copia un ficheiro grande, e deixa en paz o cifrado SSH soportado. Un cifrado obsoleto non acurta unha ida e volta; engade un segundo problema que sobrevive ao primeiro. A referencia de git status merece unha lectura, porque o comando fai moito máis traballo do que o seu nome suxire.