gity vs Scalar, VFS for Git, and ProjFS
Microsoft's lineage of giant-monorepo tools versus a focused user-space Git accelerator. Where each fits.
When to pick gity
- You need cross-platform fsmonitor with a small footprint
- You want a CPU/battery-aware scheduler for prefetch and maintenance
- You have many worktrees and want shared cache between them
- You want a focused single-purpose binary, not a curated Git workflow
When to pick Scalar / VFS for Git
- You want partial clone and sparse checkout orchestrated for you, not just fsmonitor
- You are at the scale Scalar was built for and want the most battle-tested option
- You are on Windows and it is already installed alongside Git
- You would rather adopt one vendor-supported workflow than assemble your own
TL;DR
Scalar is a curated Git workflow for giant monorepos. It enables partial clone, sparse checkout, fsmonitor, and background maintenance with known-good defaults.
gity overlaps with Scalar in one specific area — fsmonitor + maintenance — and doesn’t try to be a Git-workflow wrapper.
Capability by capability
| Capability | Scalar | gity | Notes |
|---|---|---|---|
Partial clone (--filter=blob:none) | ✓ | (use Git directly) | gity has no partial-clone helper — git clone --filter=blob:none works fine on its own. |
| Sparse checkout (cone mode) | ✓ | (use Git directly) | Same story: Scalar’s wrapping is convenient but optional. |
| fsmonitor v2 | ✓ (uses Git’s built-in) | ✓ (own daemon) | gity’s daemon is one binary serving every registered repo; Scalar starts one fsmonitor per repo. |
| Background maintenance | ✓ (via git maintenance) | ✓ (own scheduler) | gity’s scheduler is CPU- and battery-aware; Git’s is cron-based. |
| Multi-worktree shared cache | ✗ | ✓ | gity replicates hot cache keys across worktrees of the same object store. |
| CI oneshot mode | ✗ | ✓ | gity daemon oneshot services one job and exits; Scalar has no shorter-than-daemon mode. |
| Cross-platform single daemon | (one per repo) | (one shared) | An operational difference once you register more than a few repos. |
| Windows kernel dependency | ✗ (since Scalar) | ✗ | Both are fully user-space today. |
Running them on the same machine
Only one row above is a genuine either/or. core.fsmonitor holds a single value per repository, so scalar register and gity register cannot both own the same repo. Everything else is independent: partial clone and sparse checkout are properties of the clone, not of the watcher, and a git maintenance schedule Scalar installed keeps running whether or not gity is registered.
That makes the split per repository rather than per machine. A Windows monorepo can stay on scalar register while the repos on your laptop are gity-registered, with no conflict between them, because core.fsmonitor is per-repository configuration.
For the ten-year history behind these tools, see GVFS to VFS for Git to Scalar.
Frequently asked questions
Is ProjFS still recommended?
No. Microsoft moved away from ProjFS-based VFS for Git in favour of Scalar, which is user-space. ProjFS still exists as a Windows kernel feature, but it's no longer the recommended path for Git acceleration.
What's the relationship between GVFS, VFS for Git, and Scalar?
Same lineage: GVFS (2017) → VFS for Git (2019, rebrand) → Scalar (2021, complete rethink). GVFS/VFS used the ProjFS kernel driver; Scalar uses pure user-space Git features (partial clone, sparse checkout, fsmonitor, maintenance). Scalar is what Microsoft recommends today.
Does Scalar use fsmonitor?
Yes — Scalar enables Git's built-in fsmonitor daemon when you `scalar register` a repo. gity differs by being the fsmonitor helper itself, with multi-repo and multi-worktree coordination built in.