Synthèse
When working with large monorepos, git-status(1) can be slow to determine what changed in the local worktree because Git would need to traverse the whole working tree to see which files are modified. To speed up this process, in January 2018 a setting core.fsmonitor was added in Git 2.16. Back then, you had to provide your own tool (like Watchman). When this was configured, this tool runs in the background and monitors changes on the file system. This informs Git that a file was touched and Git
When working with large monorepos, git-status(1) can be slow to determine what changed in the local worktree because Git would need to traverse the whole working tree to see which files are modified. To speed up this process, in January 2018 a setting core. fsmonitor was added in Git 2. 16. Back then, you had to provide your own tool (like Watchman).
When this was configured, this tool runs in the background and monitors changes on the file system. This informs Git that a file was touched and Git then verifies whether the file was modified and updates the cached status. Then whenever the user calls git-status(1), it can simply return the cached status. In April 2022, the setting core. fsmonitor was changed to accept a boolean value.
When this setting is set to true, a daemon built-in into Git is used and no more third-party tool is needed. But this filesystem monitor was only implemented for Windows and macOS, support for GNU/Linux did not yet exist. This changes in Git 2. 55, where support for Linux has been added, too. To achieve this, inotify(7) is used.
inotify(7) was chosen over fanotify(7) because fanotify(7) requires elevated privileges. This comes with a small caveat though, the fsmonitor needs to put a watcher on each and every directory in the repository. In a large repo you might hit the limit of inotify watches (fs. inotify. max_user_watches), which you may need to raise.
These changes were submitted by Paul Tarjan based on work by Eric DeCosta and Marziyeh Esipreh.
Source originale
git-scm.com