Git 2.37 récupère bien plus rapidement le statut d’un projet sur macOS

Nicolas Furno |

Les plus gros projets de développement vont devenir beaucoup plus faciles à gérer grâce à une mise à jour de Git, un outil de versionnement bien connu des développeurs, même s’ils ne sont pas les seuls à les utiliser1. Comme tous les outils similaires, son rôle est non seulement de suivre toutes les modifications apportées à un projet, mais aussi de les enregistrer. Tout ce que vous faites depuis la création du projet est stocké, ce qui peut vite représenter des centaines de méga-octets et milliers de fichiers, voire des dizaines de giga-octets et millions de fichiers pour les projets les plus gros et anciens.

Un bon exemple de projet de grosse taille et avec un long historique pourrait être WebKit, le moteur d’affichage de Safari, dont le dépôt Git proposé sur GitHub contient plus de 250 000 « commits » (des modifications qui touchent en général plusieurs fichiers) qui remontent jusqu’au 24 août 2001. Près de 21 ans d’histoire, sachant que le WebKit des débuts n’a sans doute plus grand-chose à voir avec l’actuel, et qu’un moteur d’affichage web nécessite énormément de fichiers. Pour vous donner une idée, le projet actuel nécessite de télécharger plus de 12 Go de données pour récupérer plus de 361 000 fichiers différents.

Gérer cet historique est une tâche plus complexe qu’il n’y paraît, même pour un ordinateur aussi puissant que mon Mac Studio avec sa puce Apple M1 Max. Quand j’ouvre le dossier qui contient le projet WebKit dans le terminal, il lui faut quelques secondes pour me rendre la main2. Cela correspond au temps nécessaire pour analyser chaque fichier et vérifier s’il a été modifié par rapport au serveur. La commande git status donne une information similaire et elle a aussi besoin de plusieurs secondes pour donner son résultat.

Jusque-là, Git avait du mal à gérer les très gros projets comme celui de WebKit, y compris depuis la ligne de commande fournie par le terminal. Il faut une vingtaine de secondes ici pour ouvrir le dossier et obtenir un statut du projet.

Les créateurs de Git ont sorti une mise à jour qui apporte une amélioration sur ce point précis. Avec la version 2.37, on peut activer un nouvel outil de surveillance des fichiers intégré à Git. Il n’est pas actif par défaut et doit être mis en route avec cette commande saisie dans chaque dépôt : git config core.fsmonitor true. Une fois que c’est fait, la différence est spectaculaire : sur le même Mac Studio et le même projet WebKit, l’entrée dans le dossier puis l’obtention du statut sont quasiment instantanées. Notez aussi que la charge CPU (pourcentage en haut) reste basse, alors que le processeur était fortement exploité auparavant.

Les mêmes opérations réalisées avec Git 2.37 sont nettement plus rapides.

Ce changement est disponible sur macOS et sur Windows. Notez que la version de Git fournie avec macOS est trop ancienne pour en bénéficier, vous devrez installer une copie à jour, ce qui peut être aisément effectué avec le gestionnaire de paquets Homebrew (brew install git). D’autres options sont proposées sur le site officiel.


  1. Nous l’utilisons au sein de la rédaction pour le suivi de version de nos livres, par exemple.  ↩︎

  2. Cette latence est liée à une fonction spécifique que j’ai activée dans mon terminal : via oh-my-zsh, je peux obtenir des informations sur le dépôt Git actif, notamment pour connaître la branche en cours et savoir s’il y a des modifications locales. Avec un terminal « standard », l’ouverture serait immédiate, car toute la partie Git serait ignorée.  ↩︎


avatar YuYu | 

Question bête :
Comment faites-vous pour afficher la charge processeur et mémoire dans iTerm2 ?

avatar ssssteffff | 

@YuYu

Dans les préférences d'iTerm2 : Profiles / Session / Status bar enabled / Configure Status Bar, et vous pouvez y choisir les widgets à afficher.

avatar YuYu | 

@ssssteffff

👌
Merci pour votre réponse ;)

avatar saoullabit | 

@ssssteffff

Merci !!!

avatar ssssteffff | 

Bonne nouvelle !
Pour la latence au changement de répertoire, cela vient de votre prompt (qui appelle git status et compagnie pour afficher l’état du projet en cours). Ça découle des lenteurs de git, mais parce que votre Shell a été configuré pour (avec la configuration par défaut il n’y aurait pas cette lenteur).

avatar kiddsoso | 

@ssssteffff

Ça m’intéresse 🤔
Comment sait tu que cela vient du prompt et comment y remédier ?

avatar Nicolas Furno | 

@kiddsoso

Dans mon cas, c'est oh-my-zsh qui affiche les informations Git en permanence, par exemple la branche active ou encore si des changements locaux n'ont pas été enregistrés. Tout cela dépend du statut, ce qui explique en effet le temps de latence quand j'ouvre un dépôt Git.

avatar kiddsoso | 

@nicolasf

Ah merci ! 😀

avatar ssssteffff | 

@kiddsoso

Le thème utilisé ressemble à robbyrussell proposé par Oh My ZSH (ce n'est peut-être pas le cas, mais visuellement ça y ressemble). Le "(main)" que vous voyez dans le prompt est la branche courante vient de là. Selon les thème, cela peut afficher l'état de la branche courante (commit en cours, fichiers modifiés, etc.).
Personnellement j'utilise le thème agnoster (qui nécessite les font powerline pour s'afficher correctement, si jamais).

Edit : je n'avais pas rafraichi la page avant de poster, Nicolas a déjà répondu.

avatar alohabobo | 

@ssssteffff

Je me demande si p10k dans ce cas précis ferait pas des merveilles au démarrage (https://github.com/romkatv/powerlevel10k)

avatar ssssteffff | 

@alohabobo

Je ne connaissais pas, je vais regarder ça, merci !

avatar kiddsoso | 

@ssssteffff

Merci pour ta réponse 👍
Perso je préfère le thème avit pour la visualisation des branches, ça prends pas de temps, c’est simple et efficace

avatar Nicolas Furno | 

@ssssteffff

En effet, je ne voulais pas trop entrer dans les détails techniques (parce que déjà que c'est bien technique), mais je vais glisser un mot.

avatar Portanoo | 

Ah oui ça m’intéresse la config dans iTerm2 pour avoir les infos CPU et Mémoires

avatar Nicolas Furno | 

@Portanoo

Les explications sont disponibles un petit peu plus haut, @ssssteffff les a données. Tout se fait en effet dans les réglages d'iTerm, c'est l'une des fonctions fournies par défaut.

avatar nononap | 

Par rapport à la taille du repository, le mieux est encore de ne récupérer que les modifications récentes pour éviter un repository trop gros en local (--depth lors du fetch ou du clone).

En tout cas, ce "core.fsmonitor" est une bonne chose, j'imagine que ça utilise le même API que Time Machine sur macOS (càd FSEvent*).

avatar fabiendirect | 

Pour mon grand projet de haie, je ne pense pas que Git va beaucoup m’aider !

avatar kiddsoso | 

@fabiendirect

?

avatar nononap | 

@kiddsoso

Je suspecte une blague sur l'élagage (pruning), mot souvent utilisé pour parler de la réduction de la taille des graphes ou des arbres en informatique… mais pas sûr… ^^'

avatar kiddsoso | 

@nononap
🤯

avatar Gueven | 

Pour info, il y a moyen d’améliorer le prompt pour que le status git soit affiché de manière asynchrone dans zsh (mafredri/zsh-async).

avatar nmo | 

“ qui peut être aisément effectué avec le gestionnaire de paquets Homebrew (brew install git)”

Aisément certes, mais pas proprement.

Home brew est a éviter à tous prix. Il ne respecte pas plusieurs conventions de macOS (installe les paquets n’importe où) et contient des défauts de sécurité jamais corrigés.

MacPorts est largement préférable.

CONNEXION UTILISATEUR