El problema del recorrido status

git status compara el árbol de trabajo con el índice, recorriendo la stat info de cada archivo rastreado. En un repo de un millón de archivos esto puede tomar segundos. Fsmonitor usa las notificaciones de cambio de archivos del SO (FSEvents en macOS, ReadDirectoryChangesW en Windows, inotify en Linux).

Daemon integrado (Git 2.36+)

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

Integraciones externas

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

Verificar

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

Cache de untracked

git config core.untrackedCache true

Números de rendimiento

En un monorepo de 4 millones de archivos, git status baja de 5+ segundos a menos de 200ms.

Errores comunes

Habilitar fsmonitor sin cache de untracked. Ejecutar en un filesystem de red que no soporta eventos de cambio.

Advertencias por plataforma

• macOS: FSEvents es confiable.
• Windows: ReadDirectoryChangesW; funciona bien en NTFS.
• Linux: los límites de inotify pueden necesitar elevarse.

sudo sysctl fs.inotify.max_user_watches=524288