gity vs Git's Built-in fsmonitor
A repository can point `core.fsmonitor` at exactly one watcher, so this is a per-repo decision rather than a stack. What Git's own daemon covers, what gity adds, and how to choose.
When to pick gity
- You want a single daemon to manage many registered repos
- You need background prefetch and maintenance with a CPU/battery-aware scheduler
- You have multiple worktrees of the same monorepo and want a shared cache
- You run CI runners that need short-lived (oneshot) acceleration
- You want subscribe APIs for IDE integrations
When to pick Native fsmonitor
- You have a handful of small-to-medium repos
- You already have `git maintenance start` configured and don't need anything else
- You want absolute minimum surface area — no extra binary to install
- You're not running CI / ephemeral environments
TL;DR
Git 2.37 quietly shipped a built-in fsmonitor daemon. For the canonical “make git status fast in this one repo” case, it’s all you need:
git config core.fsmonitor true
git update-index --fsmonitorDone. No extra install, no extra daemon to manage. git status returns in tens of milliseconds.
gity adds value beyond this baseline:
- Background maintenance + prefetch on a CPU- and battery-aware scheduler.
- One daemon for many repos instead of one daemon per repo.
- Multi-worktree cache sharing.
- CI oneshot mode.
- Pub/sub subscribe API for IDEs.
When the built-in is enough
You have a few repos, no CI to worry about, no worktrees, and you’re happy to configure git maintenance start manually on each machine. The built-in daemon is genuinely good for this case.
When gity earns its keep
You manage many repos (or one very large one with many worktrees), you want one tool to handle fsmonitor and prefetch and maintenance with one command, you run ephemeral CI runners, or you want IDEs to subscribe to changes instead of polling.
For deeper details, see our full comparison post.
Frequently asked questions
What happens to my existing `core.fsmonitor` setting when I register with gity?
`gity register` writes the gity helper into that repo's Git config in place of whatever was there, and remembers the previous value. `gity unregister` puts the old value back and removes the hook, so a repo that was on Git's built-in daemon goes back to it with one command.
Are they mutually exclusive?
Per-repo, yes — `core.fsmonitor` can be `true` (built-in) or a path to a helper (e.g., gity), not both. Nothing about either choice is machine-wide, so you can mix and match across repos: gity for the monorepo, built-in for everything else.
Is there a reason to stay on the built-in daemon for a large repo?
Fewer moving parts. It is already installed, there is nothing extra to keep updated, and for one large repo with no worktrees and no CI it does the same fsmonitor work. The reasons to add gity are the things the built-in daemon does not do at all: one daemon across many repos, a cache shared between worktrees, its own prefetch and maintenance schedule, oneshot mode for CI, and a subscribe API for editors.