gity vs Watchman: Which Git Accelerator Should You Use?

Watchman is the OG of file-watching daemons. Meta built it for their internal monorepo, open-sourced it, and it now powers Jest, Mercurial, Buck, and Git’s fsmonitor on millions of developer machines. Anyone shipping a Git accelerator today has to answer the “why not just Watchman?” question. Here’s our honest take.

What they have in common

Both gity and Watchman:

• Are long-running daemons that listen to OS-native file events (inotify / FSEvents / ReadDirectoryChangesW).
• Implement Git’s fsmonitor v2 protocol, so git status can ask “what changed?” instead of walking the tree.
• Work cross-platform on macOS, Linux, and Windows.
• Are free and open-source (Watchman is BSD-3, gity is MIT).
• Will give you roughly the same git status speedup — both reduce a multi-second walk to a few milliseconds.

If you only care about the fsmonitor speedup, both are excellent. The question is what else you need.

What Watchman does that gity doesn’t

• Generality. Watchman is a watcher framework, not a Git accelerator. It exposes a query language (think SQL for files) and has bindings in Python, C, JavaScript, and Lua. Tools like Jest plug into it for their --watch modes. If you already run Watchman for these things, adding Git fsmonitor support is free.
• A trigger system. You can ask Watchman to run a shell command whenever a file matching a pattern changes. Useful for code generators, asset rebuilders, and IDE integrations.
• A larger and more battle-tested codebase. Watchman has been deployed on Meta-scale repos for over a decade. Its corner-case handling is excellent.

What gity does that Watchman doesn’t

• Background git maintenance + git prefetch. Watchman watches files; it doesn’t know anything about Git objects. With gity, registered repos get prefetch and maintenance for free, scheduled by a CPU- and battery-aware scheduler. Watchman has no equivalent.
• Warm status cache shared across worktrees. If you have three worktrees of the same monorepo (main, feature-x, hotfix), gity recognizes that they share an object store and replicates hot cache keys across them. Watchman treats each worktree as a totally independent watched tree.
• One install, one command. gity register <path> configures the fsmonitor hook automatically. With Watchman you also need to invoke Watchman watch <path> and set core.fsmonitor to a helper script (the Watchman project ships a Perl one, git-watchman.pl).
• CI oneshot mode. gity daemon oneshot <repo> services a single Git invocation in CI and then exits. Watchman has no equivalent shorter-than-daemon mode; running it in CI requires more orchestration.
• A single small binary. gity is ~12 MB; Watchman with Python bindings can pull in a much larger install tree depending on the package source.

Performance: roughly the same

For git status, both daemons turn an 8-second walk into a 20–30ms IPC round-trip. The architectural details differ — Watchman uses a JSON-over-Unix-socket protocol, gity uses Git’s v2 binary framing directly — but the user-visible speedup is comparable.

Where you may see a difference:

• Cold-start latency. gity’s v2 binary protocol shaves ~3–5ms off each call compared to Watchman’s Perl helper. Hard to notice in interactive use; visible in tight IDE polling loops.
• Worktree switching. gity’s shared cache makes the first git status after a git checkout new-feature-branch instant. Watchman has to re-prime its cache.

Both are fast enough that you will not notice the difference in normal use. The question is overall ergonomics, not microbenchmarks.

When to pick which

Pick Watchman if:

• You already run it for Jest, Mercurial, Buck, or other tooling.
• You need the trigger system to run arbitrary shell commands on file changes.
• You want maximum generality and battle-testing on Meta-scale repos.

Pick gity if:

• Your only goal is fast Git operations on large repos.
• You want one command to set up acceleration and schedule background prefetch + maintenance.
• You want a small single binary you can drop in via your package manager of choice.
• You work with multiple worktrees of the same monorepo.
• You run CI on ephemeral machines and want a “service one Git command and exit” mode.

Can you run both?

In principle, yes — Watchman handles your Jest watches, gity handles your Git acceleration. In practice, both watchers will register inotify (or FSEvents) handles for the same files, which doubles kernel resources. If both daemons are correctly tuned for their workloads, the overhead is small. But it’s still cleaner to pick one.

Try gity

cargo install gity
gity register .
git status   # was seconds, now milliseconds

If you’ve been running Watchman just for git status and don’t use the other features, gity will probably feel like a noticeable simplification. If Watchman is load-bearing for the rest of your toolchain, keep it.