git status se arrastra por SSHFS sobre una VPN: mueve el trabajo

Copia un archivo de 200 MB y vuela. Ejecuta git status en ese mismo directorio y la espera es lo bastante larga para cambiar de contexto. Esas dos observaciones no se contradicen, porque la transferencia masiva mide el caudal mientras que Git mide cuántas preguntas pequeñas al sistema de archivos puede hacer por segundo, y un árbol remoto montado convierte cada pregunta en una ida y vuelta. Ajustar la VPN no arreglará una carga de trabajo mal formada.

Por qué status es la referencia equivocada

Git tiene que saber de muchos archivos: cuáles están modificados, cuáles no están rastreados y si los datos de índice en caché siguen coincidiendo con lo que hay en disco. Sobre SSHFS cada una de esas observaciones puede ser una operación de red. La unidad de trabajo aquí es el número de archivos, no los megabytes.

Por eso el primer status tras un clon es lento, y por eso los siguientes pueden ser aún más lentos en un árbol lleno de salida de compilación. El escaneo de no rastreados recorre directorios que quizá no te importen, y cada paso es otra petición por el enlace. En una ruta de 40 ms un árbol con unos miles de entradas se convierte en unos miles de idas y vueltas. No hace falta capturar paquetes para confirmar esa aritmética.

Una prueba de descarga te dice que el enlace va bien; no dice nada sobre si mil lecturas pequeñas terminarán esta tarde.

Mueve el árbol de trabajo, no los botones de ajuste

Un clon local pone el árbol de trabajo, el índice y las operaciones de Git en la misma máquina. Un pull pasa a ser un paso de red visible en lugar de serlo cada comprobación de archivo.

Esto encaja siempre que el desarrollador pueda tener el código fuente necesario en local, que es la mayoría de las veces. También afina la frontera entre el commit y el despliegue, porque editar un archivo local ya no cambia por accidente un servicio remoto en marcha; el cambio tiene que enviarse y desplegarse como cualquier otra cosa. La contrapartida es que el código existe en dos sitios, así que decide qué copia es la autoritativa y cómo vuelve al repositorio un arreglo urgente del servidor. Esa conversación es más barata que un comando status que nadie quiere ejecutar.

Si el espacio de trabajo debe quedarse remoto, ejecuta Git allí

A veces el espacio de trabajo no puede moverse: la compilación necesita ese entorno, los datos son demasiado grandes o la política mantiene el código en el host. Entonces ejecuta Git y las herramientas de desarrollo pertinentes junto a los archivos, mediante un shell remoto aprobado o un entorno de desarrollo remoto. El editor puede quedarse en el portátil mientras su backend trabaja junto al árbol de trabajo.

Las operaciones caras ocurren entonces en local en el host remoto, y la red transporta el tráfico del editor en lugar de miles de llamadas stat. Es el mismo arreglo que un clon local, expresado como una decisión de despliegue y no como una migración.

La sincronización es un flujo de trabajo con dueños, no una caché

Un espacio de trabajo sincronizado puede recortar lecturas remotas repetidas, pero no es una caché transparente. Necesita un dueño para cada cambio, una regla para los conflictos y un acuerdo sobre los archivos generados que ambas partes creen poseer. Sin esas reglas el arreglo crea desacuerdo en lugar de comodidad.

Un sincronizador bidireccional sin ellas produce un problema distinto del que resolvió, normalmente una fusión que nadie puede atribuir. Evita ejecutar dos procesos de Git sobre un árbol de trabajo compartido salvo que entiendas cómo se coordinan.

Luego ajusta, y mantén SSH sensato

Cuando el arreglo es correcto, dos ajustes cambian sobre cuántos archivos tiene que preguntar Git: status.showUntrackedFiles y la caché de no rastreados detrás de core.untrackedCache. Ninguno cambia lo que cuesta cada pregunta a través de 40 ms; solo cambian cuántas preguntas hay. Gira un botón solo cuando las idas y vueltas sean locales.

Mide el tiempo del comando que te fastidia en lugar de razonar desde una prueba que copia un archivo grande, y deja en paz el cifrado SSH compatible. Un cifrado obsoleto no acorta una ida y vuelta; añade un segundo problema que sobrevive al primero. La referencia de git status merece una lectura, porque el comando hace mucho más trabajo del que su nombre sugiere.