Why We Built gity

This is the short version of how gity came to exist.

The premise

In late 2025, I was working on a Rust project that lived in a monorepo with about 180,000 tracked files. git status took six seconds. Every save, every focus change, every casual git status from the terminal — six seconds.

I knew about fsmonitor. I’d looked at Watchman a few times over the years. I’d seen Microsoft’s Scalar. I’d even read the upstream Git daemon docs. Each time, the conclusion was the same: “this exists, but the setup is fiddly enough that I’ll just live with the six seconds.”

Eventually I decided the setup was the actual problem. The fsmonitor v2 protocol is small. The hard part is not the protocol; it’s making it one-command to install, one-command to register, and zero-thought to maintain.

That’s the thesis behind gity. Don’t invent anything; just package up known-good ideas in a binary that’s small enough to install everywhere and opinionated enough to never need configuration.

The design constraints

I wrote down what I wanted before I wrote any code:

1. One small binary. Not a Python package with a daemon and a helper script. Not a Node package with a postinstall. Just a binary. Install via cargo / brew / npm / pip / .deb / .pkg / MSI — same bits, just packaged differently.
2. One command to set up. gity register <path>. Reads your Git config, writes the fsmonitor hook, schedules maintenance, exits. If unregister doesn’t restore the prior state perfectly, that’s a bug.
3. No configuration files. Defaults should be right. Edge cases (resource caps, scheduler tuning) live in gity health and are tweakable but rarely need to be.
4. Cross-platform with no per-OS code in user-facing places. The watcher is per-OS internally (notify crate abstracts FSEvents / inotify / ReadDirectoryChangesW). The CLI, the IPC protocol, the scheduler — those are platform-neutral.
5. Cheap to run when idle. ~12 MB resident, <0.1% CPU at rest. Anything more is a regression to be fixed.
6. Honest about what it doesn’t do. gity health shows what’s scheduled, what failed, what the resource budget is. No magic — if something isn’t working, you should be able to see why.

These constraints shaped almost every later decision.

Rust because of the constraints

Rust wasn’t the goal; it was the consequence of the constraints. A daemon running 24/7 needs bounded memory — Rust’s ownership model gets that for free. Sub-millisecond IPC needs no GC pauses — same. A single binary across platforms is a one-line cargo build --release — same. The notify crate is excellent for cross-platform watching. The sled embedded database is excellent for persistent state. The rykv replication crate is excellent for cross-worktree cache sharing.

If those crates didn’t exist, this would have been a longer project. Because they do, gity is mostly glue code around well-tested foundations.

What’s in the box

The current shape (v0.1.2):

• gity binary — ~12 MB stripped, single-file install.
• fsmonitor v2 helper — speaks Git’s protocol directly. Sub-millisecond IPC.
• Sled-backed persistent cache — survives reboots; warm git status returns in microseconds.
• Scheduler — runs prefetch and maintenance. CPU- and battery-aware.
• Cross-worktree replication — hot keys mirrored across worktrees of the same object store.
• Daemon oneshot mode — for CI runners that need acceleration for one job.
• Subscribe API — pub/sub for IDE integrations.
• Optional system tray UI — Linux (GTK), macOS, Windows. Compiles in with --features tray.

There’s also a gity demo command that races vanilla Git against gity in a TUI on whatever repo you point it at. It’s the fastest way to see the speedup on your own machine.

What’s intentionally not in the box

A few things we don’t ship and probably never will:

• A custom fork of Git. The fsmonitor protocol is part of upstream Git; we honour it. No fork, no patch, no replacement.
• A VFS layer. ProjFS-style virtualization is too heavy for our user-space model. Scalar covers this case; we don’t try to.
• Cloud features. No telemetry, no remote state, no SaaS. The daemon talks to your Git, to your filesystem, and to nothing else.
• Configuration files. There’s no ~/.config/gity/gity.toml. Everything is exposed via the CLI; defaults are right.

The org

Neul Labs is a small studio I run that ships focused developer tools. gity is the first one to a wider audience. The next few are in early stages — different problem spaces, same underlying philosophy: small, focused, honest about what they do, easy to install everywhere.

Where to start

cargo install gity
gity register .
git status

If you maintain a Git repo over 100,000 files and have lived with slow git status for any length of time, the first time you see this is satisfying.

If you have feedback, bug reports, or war stories about your own giant monorepo — open an issue on GitHub or email me directly at me@dipankar.name. Real-world feedback shapes the roadmap more than anything else.