The vocabulary behind fast Git.

fsmonitor

A Git feature that lets an external file-system monitor tell Git which files changed, so `git status` can skip walking the entire working tree. gity implements Git's fsmonitor v2 protocol.

fsmonitor v2 protocol

The wire protocol Git 2.37+ uses to ask a monitor process 'what changed since token X?' gity answers this from its watcher state, so stock Git works with no fork or patch.

daemon

A long-running background process. The gity daemon holds the file watchers, the warm cache, and the maintenance scheduler. It idles under 0.1% CPU and is roughly 12 MB resident.

OS-native file watcher

A kernel event source that reports file-system changes without polling: FSEvents on macOS, inotify on Linux, and ReadDirectoryChangesW on Windows. gity subscribes to these to detect changes in sub-milliseconds.

warm cache

gity's memory-mapped store of the last known status result, kept in a sled database that survives reboots. Repeated status polls return from this cache instead of re-scanning the tree.

scheduler

The component that runs background jobs — prefetch and `git maintenance` — while respecting CPU and battery budgets, so the repo stays fast without you configuring a cron job.

prefetch

Fetching objects from remotes ahead of time so a later `git fetch` or `git pull` is fast (or works offline). gity can schedule prefetch per repo or trigger it on demand with `gity prefetch`.

git maintenance

Git's built-in housekeeping — repacking, garbage collection, commit-graph updates — that keeps a repository fast over time. gity runs it on a resource-aware schedule in the background.

oneshot mode

A CI-friendly mode (`gity daemon oneshot`) that accelerates a single command for the length of one job and exits cleanly, leaving no persistent daemon on an ephemeral runner.

IPC

Inter-process communication. gity exposes a pub/sub IPC channel so editors and tools can subscribe to change events (`gity events`) instead of polling `git status`.

working tree

The checked-out files you edit, as opposed to the Git object database. Its size — the number of tracked files — is what makes vanilla `git status` slow, because Git stats every path.

index

Git's staging area: a snapshot of the working tree used to build the next commit. `git status` compares the working tree against the index, which is the operation gity accelerates.

drop-in

gity requires no change to your Git workflow. After `gity register`, plain Git commands are accelerated transparently — there is no alias, wrapper, or fork of Git to adopt.

worktree

An additional checkout of the same repository (`git worktree add`). gity shares one warm cache across a repo's worktrees, so a fresh worktree isn't a cold start.

Keep reading: architecture · CLI reference · fsmonitor protocol explained · FAQ