The questions developers ask, answered.

Each of those covers a narrower slice. `core.untrackedCache` caches the untracked-file listing per directory and does nothing for tracked files, so it stacks with everything else and you should enable it either way. Git's built-in fsmonitor daemon (2.37+) handles tracked files well, one daemon per repository, and leaves prefetch and maintenance to you. Watchman is a general-purpose file-watching framework that also speaks fsmonitor. Scalar is Microsoft's wrapper that turns on Git's whole large-repo feature set together. gity runs one daemon for every registered repo, shares its cache across worktrees of the same object store, schedules prefetch and maintenance itself, and has a oneshot mode for CI. Since `core.fsmonitor` holds a single value per repo, gity, the built-in daemon and Watchman are alternatives to each other, not a stack.

`gity register <path>` starts the daemon if it isn't running, attaches a file watcher to the repo, and writes the fsmonitor hook into that repo's Git config. Nothing else in your workflow changes: plain `git status`, `git diff` and every IDE call are accelerated with no alias, no wrapper, and no forked Git in the way. `gity unregister <path>` detaches the watcher, removes the hook from `.git/config`, restores the previous configuration and clears that repo's cache, so the whole change is reversible with one command.

Running it continuously is the intended mode. The daemon is roughly 12 MB resident, idles under 0.1% CPU, throttles itself when the machine is busy, and enforces per-repo ceilings on memory and file descriptors so one repository cannot starve the others. `gity list --stats` prints CPU, RSS, file descriptors and cache hit rate for every registered repo; `gity health <path>` reports watcher tokens issued, scheduler queue depth, the current resource budget, and the last prefetch and maintenance runs for a single repo.

gity does not rewrite or modify Git history, does not upload anything anywhere, and does not need admin privileges — it is a user-space process talking to Git over a documented protocol. It also does not try to be a Git workflow wrapper: partial clone, sparse checkout and index tuning stay ordinary Git commands. It will not even enable `core.untrackedCache` for you, though we recommend it, because `gity register` should not change your Git config beyond the fsmonitor hook it needs.

gity is MIT-licensed and the source is on GitHub. Every channel is free: crates.io, Homebrew, npm, PyPI, snap and Chocolatey, plus .deb, .pkg, .msi and .tar.gz artifacts on GitHub Releases — nine ways to install the same portable binary across macOS, Linux and Windows. Publishing runs through OIDC-based trusted publishing, and every release carries an attestation you can check before you run it.

macOS (Apple Silicon and Intel), Linux (x86_64 and aarch64, glibc and musl), and Windows (x86_64). The same single binary works everywhere; there are no platform-specific configuration files.

Pick your favourite package manager: `cargo install gity`, `brew install neul-labs/tap/gity`, `npm install -g gity-cli`, `pip install gity-cli`. Pre-built binaries (.deb, .pkg, .msi, .tar.gz) are also available on the GitHub releases page.

On repositories with 10,000+ tracked files we typically observe a 100x–500x speedup on `git status` once the cache is warm. The included `gity demo` command runs a side-by-side race against vanilla Git in your terminal so you can measure on your own machine.

Yes. gity recognizes that multiple worktrees share the same underlying object store and replicates hot cache keys across them, so switching to a new feature branch is instant.

Use `gity daemon oneshot <repo>` — it starts the daemon, services a single repo for the duration of your job, and shuts down cleanly. This is the recommended pattern for ephemeral CI runners where a long-lived daemon would be wasted.

`gity health <path>` shows watcher tokens, scheduler state, and the current resource budget for a single repo. `gity daemon metrics` prints aggregate daemon CPU, RSS, file descriptors, and cache hit rates across every registered repo.

Every release ships with a SLSA-style attestation. Run `gh attestation verify gity-0.1.2-x86_64-unknown-linux-gnu.tar.gz --owner neul-labs` to confirm the binary was built by our GitHub Actions workflow and not tampered with downstream.

Scalar and gity solve overlapping but different problems. Scalar is Microsoft's curated wrapper that bundles Git's performance features — partial clone, sparse-checkout, fsmonitor, and background maintenance — with known-good defaults, and it's battle-tested on Windows-scale monorepos. gity is a focused, cross-platform fsmonitor + maintenance helper: a small single-purpose binary with a CPU/battery-aware scheduler and a cache shared across worktrees, without wrapping your whole Git workflow. Both want the `core.fsmonitor` slot, so pick one per repo. See /compare/projfs-gvfs-scalar for the full breakdown.

gity is an OS-native fsmonitor daemon that speaks Git's fsmonitor v2 protocol, so `git status` returns in milliseconds even in monorepos with millions of files. Beyond raw watching, it runs background prefetch and maintenance on a CPU/battery-aware scheduler, shares its status cache across worktrees of the same repo, and services many repos from a single daemon (plus a oneshot mode for CI). Per repo, `core.fsmonitor` can be `true` or point to a helper like gity — not both. See /compare/native-fsmonitor.

Git's built-in fsmonitor (2.37+) is the zero-install baseline — enable `core.fsmonitor` and you're done for a single repo. Watchman is Meta's general-purpose file watcher (it also powers Jest, Mercurial, and Buck); it works as an fsmonitor backend but is extra software to install and tune on Linux/macOS. Scalar is Microsoft's workflow wrapper that turns on Git's performance features together for giant monorepos. gity is a focused, cross-platform native watcher — one small binary, no Watchman install, with multi-worktree cache sharing and CI oneshot mode. See /compare/watchman and /compare/projfs-gvfs-scalar.