Par Anonyme (non vérifié) , 29 avril 2026

Le problème du parcours status

git status compare l'arbre de travail à l'index, parcourant les stat info de chaque fichier suivi. Sur un repo d'un million de fichiers cela peut prendre plusieurs secondes. Fsmonitor utilise les notifications de changement de fichier de l'OS (FSEvents sur macOS, ReadDirectoryChangesW sur Windows, inotify sur Linux).

Daemon intégré (Git 2.36+)

git config core.fsmonitor true
git fsmonitor--daemon start
git fsmonitor--daemon status
git fsmonitor--daemon stop

Intégrations externes

git config core.fsmonitor /path/to/hook
git config core.fsmonitorHookVersion 2

Vérifier

GIT_TRACE2_PERF=1 git status 2>&1 | grep fsmonitor
git fsmonitor--daemon status
git update-index --fsmonitor

Cache untracked

git config core.untrackedCache true

Chiffres de performance

Sur un monorepo de 4 millions de fichiers, git status passe de 5+ secondes à moins de 200ms.

Erreurs courantes

Activer fsmonitor sans cache untracked. Lancer sur un filesystem réseau qui ne supporte pas les événements de changement.

Avertissements par plateforme

  • macOS : FSEvents fiable.
  • Windows : ReadDirectoryChangesW ; bien sur NTFS.
  • Linux : limites inotify peuvent nécessiter relèvement.
sudo sysctl fs.inotify.max_user_watches=524288