And thus, it cannot be a traditional Git hook (child) process. So it must be a long-running daemon or service process and not associated with an individual Git command instance. It responds to client requests for a list of files and directories that have been modified recently.įSMonitor must continuously watch the worktree to have a complete view of all file system changes, especially ones that happen between Git commands.It listens for IPC connections from client processes, such as git status.It adds the pathnames of those files and directories to an in-memory, time-sorted queue.It registers with the operating system to receive change notification events on files and directories.What we really need is a way to focus on the changed files without searching the entire worktree.įSMonitor is a long-running daemon or service process. In a monorepo, there might be millions of files in the worktree, so this search can be very expensive. The cost of this search is relatively fixed and is based upon the number of files (and directories) present in the worktree. Whether you edit zero, one, or a million files in the mean time, the next git status command has to do the same amount of work to rediscover what (if anything) has changed. Whether you immediately run it again or run it again tomorrow, it has to rediscover all of that same information by searching again. It does this by searching the entire worktree. That is, when you run a command that operates on the worktree, such as git status, it has to discover what has changed relative to the index. Git has a “What changed while I wasn’t looking?” problem. In this article, I’ll introduce the new builtin FSMonitor feature and explain how it improves performance on very large worktrees. _Note that when the daemon first starts up, it needs to synchronize with the state of the index, so the next git status command may be just as slow (or slightly slower) than before, but subsequent commands should be much faster. 'status -uno'įsmonitor-daemon is watching 'C:/work/chromium' It took 6.37 seconds to enumerate untracked files.

New files yourself (see 'git help status'). May speed it up, but you have to be careful not to forget to add It took 5.25 seconds to enumerate untracked files. Your branch is up to date with 'origin/main'. We’ll talk more about the untracked-cache later. A daemon will be started automatically in the background by the next Git command.įSMonitor works well with core.untrackedcache, so we’ll also turn it on for the FSMonitor test runs. To enable the new builtin FSMonitor, just set core.fsmonitor to true. It is currently available on macOS and Windows.

It only requires a config change to enable it. This is easy to set up and use since it is “in the box” and does not require any third-party tooling nor additional software. In this article, I want to talk about the new builtin FSMonitor git fsmonitor-daemon added in Git version 2.37.0. For example, this chart shows status times dropping to under a second on three different large worktrees when FSMonitor is enabled! The Git file system monitor (FSMonitor) feature can speed up these commands by reducing the size of the search, and this can greatly reduce the pain of working in large worktrees. When the worktree is very large, Git needs to do a lot of work. These commands are slow because they need to search the entire worktree looking for changes. If you have a monorepo, you’ve probably already felt the pain of slow Git commands, such as git status and git add.

Systemx macos system monitor github