Speed Up Git Status with the Built-in File Monitor

A git status that takes seconds on a huge working tree is often fixed by Git's built-in filesystem monitor. This guide checks whether your installed Git can use it, turns it on for one repository, verifies the daemon is actually watching, and shows how to undo the change cleanly. Allow about five minutes. You need a Git working tree and permission to edit its local configuration.

1. Check the Git version and platform support

Start inside the repository you want to test, and run this as your ordinary user. Do not jump straight to setting core.fsmonitor, support is platform and build dependent, and a configuration value alone will not make an unsupported daemon work:

cd /path/to/repository
git --version
git fsmonitor--daemon status

On a supported installation, an inactive daemon normally makes status exit non-zero, which is different from an unsupported build. For example, the Git 2.43.0 installed on the machine used for this guide reports:

git version 2.43.0
fatal: fsmonitor--daemon not supported on this platform

Seeing that message means you stop here and leave core.fsmonitor unset. The rest of this guide describes the workflow for a Git build that includes the monitor for your platform. Check git --version again after any upgrade rather than assuming a newer package is sitting in your current distribution repository.

Checkpoint: support confirmed

You should have a version string and a status result that is not an unsupported-platform error. If you are not sure, keep the monitor disabled until the command completes without that error.

2. Check the repository filesystem

The daemon watches one working directory and talks to Git through a Unix domain socket on Linux. Network-mounted repositories are refused by default, and overriding that protection does not guarantee they will work. Keep the repository and its .git directory on a native local filesystem for this test.

On Linux, the monitor uses inotify, and large repositories can hit the per-user watch limit, so record the current value before changing anything:

test -d .git && echo "Git directory found"
cat /proc/sys/fs/inotify/max_user_watches

A low watch limit is a capacity problem, not a reason to apply a random system setting you found online. If the daemon later reports an inotify watch-limit error, check your distribution's sysctl guidance first.

3. Enable the monitor for this repository

This only changes the repository's local Git configuration and needs no elevated privileges. It tells commands such as git status to use the built-in daemon and to start it when needed:

git config --local core.fsmonitor true
git config --local --get core.fsmonitor

Expected output:

true

Skip sudo for this command. Using it can write configuration or runtime files under the wrong user's home directory, which leaves your normal Git process unable to talk to the daemon at all.

4. Start and verify the daemon

Run a normal status command first. With the setting enabled, Git can start the daemon on its own.

git status --short
git fsmonitor--daemon status
echo "status exit code: $?"

The second command should exit with code 0 when a daemon is watching the current working directory. It may print nothing useful, its documented purpose is the exit status. The first status command should still show the repository's real changes. Create a harmless test file if you want proof that changes are still noticed, then remove it afterwards:

printf 'fsmonitor test\n' > .fsmonitor-test
git status --short
rm -- .fsmonitor-test
git status --short

Seeing the test file show up as untracked, then seeing it disappear, is a basic client check, not a benchmark. The actual benefit depends on repository size, filesystem speed and how often Git has to refresh the index.

Foreground mode for troubleshooting

start launches the daemon in the background. If it fails silently, run it in the foreground so the error is actually visible:

git fsmonitor--daemon stop
git fsmonitor--daemon run

run occupies the terminal until you interrupt it. Warning: this is a service-disrupting diagnostic action, do not leave it running in a shell you need for other work. Press Ctrl-C to stop it, then check from another terminal with git fsmonitor--daemon status. A foreground run is never required for ordinary use.

5. Handle common failure boundaries

If status says the platform is unsupported, remove the setting and fall back to ordinary Git status:

git config --local --unset core.fsmonitor || true
git fsmonitor--daemon stop || true
git status --short

If the repository sits on a network mount, move or clone it to local storage before testing further. The fsmonitor.allowRemote setting exists to override that refusal, but the manual marks network-mounted use as experimental. Do not enable it just to silence an error.

If a daemon is stale or simply unwanted, stopping it is safe and reversible. The configuration can stay enabled, in which case a later Git command may start it again. To disable the feature completely:

git fsmonitor--daemon stop
git config --local --unset core.fsmonitor

The daemon does not treat submodules as separate event sources. A change inside a submodule can get reported to the superproject as an extra event, though Git's client filters it and should not produce an incorrect result, just expect a bit less of the performance benefit in repositories with many submodules.