git status rampe sur SSHFS via un VPN : déplacez le travail

Copiez un fichier de 200 Mo et il file. Lancez git status dans le même répertoire et l'attente est assez longue pour passer à autre chose. Ces deux observations ne se contredisent pas, car le transfert en masse mesure le débit tandis que Git mesure combien de petites questions au système de fichiers il peut poser par seconde, et un arbre distant monté transforme chaque question en aller-retour. Régler le VPN ne réparera pas une charge de travail mal formée.

Pourquoi status est le mauvais repère

Git doit apprendre beaucoup de choses sur les fichiers : lesquels sont modifiés, lesquels ne sont pas suivis et si les données d'index en cache correspondent encore à ce qui est sur le disque. Sur SSHFS, chacune de ces observations peut être une opération réseau. L'unité de travail ici est le nombre de fichiers, pas les mégaoctets.

C'est pourquoi le premier status après un clone est lent, et pourquoi les suivants peuvent l'être encore plus dans un arbre plein de sorties de compilation. L'analyse des fichiers non suivis parcourt des répertoires qui ne vous intéressent peut-être pas, et chaque étape est une requête de plus sur le lien. Sur un trajet à 40 ms, un arbre de quelques milliers d'entrées devient quelques milliers d'allers-retours. Aucune capture de paquets n'est nécessaire pour confirmer cette arithmétique.

Un test de téléchargement vous dit que le lien va bien ; il ne dit rien sur la question de savoir si mille petites lectures finiront cet après-midi.

Déplacez l'arbre de travail, pas les boutons de réglage

Un clone local place l'arbre de travail, l'index et les opérations Git sur la même machine. Un pull devient une étape réseau visible au lieu de l'être à chaque vérification de fichier.

Cela convient chaque fois que le développeur peut garder la source nécessaire en local, ce qui est le plus souvent le cas. Cela affûte aussi la frontière entre commit et déploiement, car modifier un fichier local ne change plus par accident un service distant en fonctionnement ; la modification doit être poussée et déployée comme tout le reste. La contrepartie est que le code existe à deux endroits : décidez quelle copie fait autorité et comment un correctif urgent sur le serveur revient dans le dépôt. Cette conversation coûte moins cher qu'une commande status que personne ne veut lancer.

Si l'espace de travail doit rester distant, exécutez Git là-bas

Parfois l'espace de travail ne peut pas bouger : la compilation a besoin de cet environnement, les données sont trop grosses ou la politique garde la source sur l'hôte. Exécutez alors Git et les outils de développement concernés à côté des fichiers, via un shell distant approuvé ou un environnement de développement distant. L'éditeur peut rester sur l'ordinateur portable pendant que son backend travaille à côté de l'arbre de travail.

Les opérations coûteuses se déroulent alors en local sur l'hôte distant, et le réseau transporte le trafic de l'éditeur au lieu de milliers d'appels stat. C'est le même correctif qu'un clone local, exprimé comme un choix de déploiement plutôt que comme une migration.

La synchronisation est un flux de travail avec des propriétaires, pas un cache

Un espace de travail synchronisé peut réduire les lectures distantes répétées, mais ce n'est pas un cache transparent. Il a besoin d'un propriétaire pour chaque changement, d'une règle pour les conflits et d'un accord sur les fichiers générés que les deux côtés croient posséder. Sans ces règles, l'arrangement crée du désaccord plutôt que du confort.

Un synchroniseur bidirectionnel sans elles produit un problème différent de celui qu'il a résolu, généralement une fusion que personne ne peut attribuer. Évitez de lancer deux processus Git sur un arbre de travail partagé si vous ne comprenez pas comment ils se coordonnent.

Réglez ensuite, et gardez SSH raisonnable

Une fois l'arrangement correct, deux réglages changent le nombre de fichiers sur lesquels Git doit s'interroger : status.showUntrackedFiles et le cache des non suivis derrière core.untrackedCache. Aucun ne change ce que coûte chaque question sur 40 ms ; ils changent seulement le nombre de questions. Ne touchez à un bouton qu'une fois les allers-retours locaux.

Chronométrez la commande qui vous agace plutôt que de raisonner à partir d'un test qui copie un gros fichier, et laissez tranquille le chiffrement SSH pris en charge. Un chiffrement obsolète ne raccourcit pas un aller-retour ; il ajoute un second problème qui survit au premier. La référence de git status vaut une lecture, car la commande fait bien plus de travail que son nom ne le suggère.