Von Gast (nicht überprüft) , 29 April 2026

Das Status-Walk-Problem

git status vergleicht den Working Tree mit dem Index und durchquert die stat-Info jeder verfolgten Datei. Auf einem Repo mit einer Million Dateien kann das Sekunden dauern. Fsmonitor verwendet die Datei-Anderungs-Benachrichtigungen des Betriebssystems.

Eingebauter Daemon (Git 2.36+)

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

Externe Integrationen

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

Verifikation

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

Untracked Cache

git config core.untrackedCache true

Performance-Zahlen

Auf einem 4-Millionen-Datei-Monorepo sinkt git status von 5+ Sekunden auf unter 200ms.

Haufige Fehler

Fsmonitor ohne Untracked Cache aktivieren — nur halber Gewinn.

Vorbehalte pro Plattform

  • macOS: FSEvents ist zuverlassig.
  • Windows: ReadDirectoryChangesW.
  • Linux: inotify-Limits (fs.inotify.max_user_watches).
sudo sysctl fs.inotify.max_user_watches=524288