Use case · Monorepos
Make your million-file monorepo feel small.
In a working tree with hundreds of thousands of files, vanilla git status
walks the entire tree on every call. gity attaches an OS-native file watcher and
speaks Git's fsmonitor v2 protocol, so Git only checks the handful of files that
actually changed.
The problem
Monorepos concentrate everyone's code in one working tree. That's great for
refactors and atomic changes — and brutal for Git, because most Git commands
start by asking "what changed?" To answer, Git lstat()s every tracked
path. At a few hundred thousand files, a cold git status can take
several seconds. Multiply that by every developer, every branch switch, and every
IDE poll, and the monorepo tax becomes real wall-clock time.
How gity fixes it
- OS-native watching. gity subscribes to FSEvents (macOS), inotify (Linux), or ReadDirectoryChangesW (Windows) for your repo. The kernel tells it which paths changed — no polling, no tree walk.
- fsmonitor v2. When Git runs
status, it asks gity (over Git's documented fsmonitor protocol) "what changed since token X?" gity answers instantly from its watcher state, and Git only re-scans those paths. - Warm cache across worktrees. The daemon keeps a memory-mapped cache that survives reboots and is shared across multiple worktrees of the same repo, so a fresh worktree isn't a cold start.
Set it up once
# register the monorepo — starts the daemon, installs the hook
gity register ~/work/monorepo --prefetch --maintain
# from now on, plain Git is fast
cd ~/work/monorepo
git status # milliseconds, not seconds
The --prefetch and --maintain flags schedule background
fetch and git maintenance so the repo stays fast without a cron job.
See the full flow in the quickstart.
What you can expect
On a representative ~250k-file repo, the demo TUI shipped with gity
(gity 0.1.2) measures a cold git status dropping from
roughly 8.2 s to tens of milliseconds. These numbers are
illustrative, not certified — run gity demo on your
own repo to measure your own speedup. Full methodology lives on the
benchmarks page.
Frequently asked
How big does a repo need to be before gity helps?
The pain starts wherever `git status` becomes noticeable — usually tens of thousands of tracked files. The bigger the working tree, the larger the win, because vanilla Git's cost scales with the number of files it has to stat, while gity only re-checks what actually changed.
Does gity change anything in my repository?
It writes an fsmonitor hook into your repo's Git config on `gity register` and removes it on `gity unregister`. It never touches your history, working tree, or commits.
Does the whole team need to install gity?
No. gity is a per-developer, per-machine daemon. Each person who installs it gets a faster local Git; nobody who doesn't is affected. There is no server component to deploy.
Get gity
Try gity on your biggest repo.
One command to install, one to register, and your monorepo starts feeling like a tiny one. MIT-licensed and free to use.