GVFS to VFS for Git to Scalar: Microsoft's Monorepo Lineage

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.

Where gity sits in that lineage

gity is a user-space accelerator, which puts it on the same side of the 2021 split as Scalar: no kernel driver and no forked Git. The difference is scope. Scalar curates Git’s whole large-repo feature set — partial clone, sparse checkout, fsmonitor, commit-graph, maintenance — while gity implements only the two parts that need a resident process: fsmonitor and background maintenance. The rest of what Scalar turns on is plain Git configuration you can set yourself, and gity deliberately leaves it alone.

The lineage argues for that narrowness. GVFS ended up deprecated because a kernel-mode virtual filesystem plus a forked Git is a large, privileged surface to keep correct across every Git operation. The smaller the resident component, the less of it there is to get wrong — and a daemon that answers “what changed since token X?” and runs git maintenance on a schedule is close to the smallest resident component that can still do the job. (The side-by-side breakdown is on the comparison page.)

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.

The short version of ten years

Microsoft tried virtualization, found it too expensive to maintain, and moved the same goal into ordinary Git configuration. Everything that made Scalar possible — partial clone, sparse checkout, fsmonitor v2, commit-graph, git maintenance — is now upstream and available to any tool that wants it. gity is one of those tools.

cargo install gity
gity register .