gity vs Scalar, VFS for Git, and ProjFS

Microsoft has spent a decade publishing increasingly sensible answers to “how do you put the Windows source into Git?” The current answer — Scalar — is genuinely good. The older answers (GVFS, VFS for Git) are interesting history. This article walks through each, what it actually does, and how gity fits next to them.

A short history of giant-monorepo Git

GVFS (2017): Microsoft’s first attempt. A virtual filesystem (using the ProjFS kernel driver on Windows) made the Windows source tree look fully present on disk while actually only downloading files you touched. Required forks of Git and depended on kernel-mode components.

VFS for Git (2019): A rebranded, more open-source version of GVFS. Same architecture — VFS on top of stock-ish Git, ProjFS on Windows.

Scalar (2021): A complete rethink. Microsoft moved away from kernel-mode VFS and into pure user-space Git. The performance came from combining features that had landed in upstream Git: partial clone (--filter=blob:none), sparse checkout, fsmonitor, commit-graph, and background maintenance. Scalar is essentially a curated configuration of these features plus a few convenience commands.

Scalar today: ships with Git for Windows and as a standalone install for macOS and Linux. The kernel VFS layer is gone; everything is user-space.

The transition from GVFS to Scalar is one of the more honest engineering retrospectives in recent history. Microsoft concluded their kernel-mode approach was the wrong abstraction, deprecated it, and shipped a simpler user-space tool. That same year, upstream Git got the features needed to make user-space competitive with the older VFS approach.

What Scalar does

scalar exposes commands that wrap Git operations and apply a known-good configuration:

scalar clone https://github.com/org/repo
scalar register /path/to/existing/clone
scalar list
scalar run all

Under the hood, scalar clone runs git clone --filter=blob:none with sparse checkout enabled. scalar register sets up background maintenance, fsmonitor, and a recommended config. scalar run invokes one of the maintenance tasks (prefetch, pack-files, commit-graph, …) on demand.

Scalar’s value proposition: “You don’t have to figure out which Git features to combine and how to schedule them — we’ll do it for you, calibrated for Microsoft-scale repos.”

What ProjFS still does (Windows only)

ProjFS hasn’t gone away; Microsoft just stopped using it as the primary path for Git. It’s still available for tools that need real virtualization — i.e., directories that don’t physically exist until something accesses them.

For Git specifically, this is no longer the recommended path. Partial clone + sparse checkout gets you most of the benefits without depending on a kernel driver.

What gity does

gity overlaps with Scalar in one specific area — fsmonitor + background maintenance — and ignores the other Scalar features (partial clone orchestration, sparse-checkout convenience commands).

Capability	Scalar	gity	Notes
Partial clone (--filter=blob:none)	✓	(use Git directly)	gity has no special partial-clone helper — git clone --filter=blob:none works fine on its own.
Sparse checkout (cone mode)	✓	(use Git directly)	Same — Scalar’s wrapping is convenient but optional.
fsmonitor v2	✓ (uses Git’s built-in)	✓ (own daemon)	gity’s daemon is a single binary handling all registered repos; 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 repo.
CI oneshot mode	✗	✓	gity has explicit short-lived-daemon support.
Cross-platform single daemon	(one per repo)	(one shared)	Operational difference for power users.
Windows kernel dependency	✗ (since Scalar)	✗	Both fully user-space now.

The picture: Scalar is a curated Git workflow for huge repos. gity is a focused daemon for the fsmonitor + maintenance subset, with extra features (shared cache, oneshot mode, subscribe API) that matter when you have many repos or run a fleet of CI machines.

When to pick which

Pick Scalar if:

• You want one tool that wraps Git’s full performance-oriented feature set and tells you the right defaults.
• You work on Windows-scale monorepos and want the convenience commands.
• You’re already in the Microsoft ecosystem and Scalar is preinstalled with Git for Windows.

Pick gity if:

• You need cross-platform fsmonitor with a small footprint.
• You want background maintenance with a CPU/battery-aware scheduler.
• You have many worktrees and want shared cache.
• You want a single daemon to manage many repos, especially in CI.
• You want a focused tool that does one thing well rather than a curated Git wrapper.

Can you use both?

In principle, yes — Scalar handles your repo wrapping, gity handles fsmonitor. In practice the two compete for the core.fsmonitor slot in your repo config. If gity is registered, Scalar’s git maintenance schedule still works fine; just be aware that the fsmonitor part is owned by gity.

The deprecated path

If you’re still on GVFS or VFS for Git, Microsoft recommends migrating to Scalar. The kernel VFS approach has known correctness issues with modern Git operations and Microsoft has stopped maintaining it. Either Scalar or a user-space accelerator like gity is the right path forward.

Try gity

cargo install gity
gity register .

If your repo is on the smaller end (under 500k files) and you don’t need Scalar’s wrapping, gity gives you the fsmonitor + maintenance subset in a single small daemon with one command.