# VFS for Git: Virtualizing a Monorepo Working Directory on Windows

> VFS for Git presents a full working tree to Git while downloading objects on demand, but the README now points new deployments at Scalar. Here is what the tool does, how it installs, and where it stops being the right choice.

**microsoft/VFSForGit** — Virtual File System for Git: Enable Git at Enterprise Scale

- Repository: https://github.com/microsoft/VFSForGit
- Stars: 6,137 · Forks: 473
- Language: C#
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-vfsforgit

## What VFS for Git virtualizes, and for whom

The problem is a working directory larger than the machine that has to hold it. The README describes the mechanism plainly: VFS for Git virtualizes the file system beneath your Git repository so that Git and all tools see what appears to be a regular working directory, but VFS for Git only downloads objects as they are needed. The second half of that sentence matters more than the first. The project also manages the files that Git will consider, so operations such as status and checkout only look at files the user has accessed rather than every file in the repository.

That combination is what separates it from a partial clone. A partial clone still materializes a working tree; VFS for Git keeps the tree virtual and fills it in lazily. The target user is an engineer on Windows inside a very large monorepo, where a full checkout is impractical and a sparse checkout still leaves too many files for Git's own scans to stay quick.

## The GVFS protocol, the PrjFlt driver and the microsoft/git fork

Three pieces have to line up. First, the client is not upstream Git. The README instructs you to install the microsoft/git fork and states that you will need to continue using the microsoft/git version of Git, which notifies you when new versions are available. Second, the server must speak the GVFS protocol, documented in Protocol.md in the repository; the README points at Azure DevOps as an example service that supports it. Third, the file system virtualization on Windows is provided through the PrjFlt filter driver, which the README notes was formerly known as the GvFlt filter driver and ships as a prerelease NuGet package.

That last detail is worth pausing on. A prerelease driver package is a dependency you inherit, not one you control, and it is Windows-only. The repository layout reflects the same split: GVFS.sln sits at the root alongside vcpkg.json and triplets/, and the build instructions call for both the .NET desktop development and Desktop development with C++ workloads in Visual Studio 2022. This is a native-plus-managed codebase, and the install footprint follows.

## Installing VFS for Git and running a first clone

The README requires Windows 10 Anniversary Update, version 1607, or later, and gives winget as the install path. Both packages are needed: the Git fork and the VFS for Git client itself.

```bash
winget install --id Microsoft.Git
winget install --id Microsoft.VFSforGit
```

Before cloning, the server side has to satisfy two constraints the README spells out. Your repository must not enable any clean or smudge filters, and it must have a .gitattributes file in the root containing the line below.

```
* -text
```

With a GVFS-protocol repository ready, for example one created in Azure DevOps, clone it with gvfs rather than git. The README is explicit that you should choose the Clone with HTTPS option in the Clone Repository dialog in Azure Repos, not Clone with SSH.

```bash
# replace with the HTTPS URL of your GVFS-protocol repository
gvfs clone <URL of repo you just created>
```

After the clone completes, change into the src directory under the clone root and run Git commands as you normally would. When you are finished, the README's last step is to release the mount.

```bash
gvfs unmount
```

What you should see during the clone is a working directory that looks complete while objects arrive on demand. If the server does not support the GVFS protocol, or the repository carries a clean or smudge filter, the clone is where that surfaces.

## Where VFS for Git fails, and why the README redirects new users

The most important limitation is stated by the project itself. For new deployments, the README strongly recommends considering Scalar instead of VFS for Git, on the grounds that Scalar combines the lessons from operating VFS for Git at scale with new developments in Git. That is not a soft caveat buried in a changelog; it is the second paragraph of the README. Anyone evaluating this repository for a fresh monorepo rollout should treat that sentence as the headline.

The constraints are also narrow. Windows 10 1607 or later is required, so macOS and Linux clients are out of scope. The server must implement the GVFS protocol, which rules out plain GitHub and most self-hosted Git servers unless something in front of them speaks it. Repositories with clean or smudge filters are excluded, and the root .gitattributes must carry '* -text'. On top of that, the client depends on the microsoft/git fork, so every developer needs that fork installed and kept current rather than whatever Git their package manager already provides. Finally, the PrjFlt filter driver is a kernel-level component distributed as a prerelease package, which is a different operational risk category from a user-space CLI.

## VFS for Git compared with Scalar and with Git partial clone

Scalar is the alternative the README names, and the difference is architectural rather than cosmetic. Scalar is described as combining lessons from operating VFS for Git at scale with new developments in Git, which places it on the upstream Git side of the line rather than on a custom client plus a filter driver. VFS for Git, by contrast, virtualizes the file system itself and requires its own clone and unmount commands.

The other comparison is with Git's own partial-clone machinery, which the related searches phrase as git clone --filter. That approach reduces what is fetched, but it still produces a real working tree and leaves Git scanning the files that exist. VFS for Git's second mechanism, managing which files Git considers, is aimed at exactly that cost. The trade is that you accept a Windows-only driver, a fork of Git and a server protocol, in exchange for status and checkout that do not scale with repository size.

## Maintenance, licensing and what a build actually costs

The repository is not archived, and the last push was on 2026-09-17, the same date as release v2.0.26259.1. The two preceding releases, v2.0.26229.1 and v2.0.26222.1, landed on 2026-08-17 and 2026-08-10. Those dates are close together, so the project is receiving changes, but the README's own recommendation for new deployments should carry more weight in an adoption decision than release cadence does.

Building your own installer is a heavier proposition than installing one. The README lists Visual Studio 2022 Community Edition or higher with the .NET desktop development and Desktop development with C++ workloads, the Windows 10 or 11 SDK, the .NET 10 SDK, and vcpkg. You clone into a src subfolder and run the build script.

```bash
src\scripts\Build.bat
```

The README notes that the script defaults to a Debug build, and that opening GVFS.sln directly in Visual Studio produces a failing first build because a prebuild code generation step is required; the second and subsequent builds succeed. The resulting installer lands at out\GVFS.Installers\bin\[Debug|Release]\win-x64\SetupGVFS.<version>.exe.

On licensing, the source code in this repository is available under the MIT license, per License.md. Two things sit outside that simple statement: the PrjFlt filter driver is distributed as a prerelease NuGet package, and the project includes or links third-party native libraries at build time, listed in THIRD-PARTY-NOTICES.md. The repository also carries GvFlt_EULA.md. Review those files against your own distribution model; this is a description of what the repository contains, not legal advice.

## Conclusion

VFS for Git is for Windows teams already running a GVFS-protocol service such as Azure DevOps who need a virtualized working directory today. It is not for new deployments: the README states that Scalar is the recommended path for large monorepos, and the tool requires the microsoft/git fork rather than upstream Git. Before adopting, verify that your hosting service supports the GVFS protocol, that your repository has no clean or smudge filters and carries '* -text' in its root .gitattributes, and that the PrjFlt filter driver installs on your Windows build.

## FAQ

### What does VFS for Git actually do to my working directory?

It virtualizes the file system beneath the repository so Git and other tools see what appears to be a regular working directory, while objects are downloaded only as they are needed. It also manages which files Git considers, so status and checkout do not scan every file in the repository.

### Which Windows versions and Git client does VFS for Git require?

The README requires Windows 10 Anniversary Update, version 1607, or later, and instructs you to install the microsoft/git fork alongside VFS for Git using winget. It states that you must keep using the microsoft/git version of Git, which notifies you about new versions.

### Can I clone any repository with gvfs clone?

No. The README requires a Git service that supports the GVFS protocol, such as Azure DevOps, and gives two constraints: the repository must not enable clean or smudge filters, and it must have a '.gitattributes' file in the root containing the line '* -text'. It also says to use the Clone with HTTPS option, not Clone with SSH.

### Should a new monorepo deployment choose VFS for Git or Scalar?

The README states that for new deployments it strongly recommends considering Scalar instead of VFS for Git, because Scalar combines lessons from operating VFS for Git at scale with new developments in Git. VFS for Git remains the option for teams already running a GVFS-protocol service.

## Sources

- [Issues](https://github.com/microsoft/VFSForGit/issues)
- [License: MIT](https://github.com/microsoft/VFSForGit/blob/master/LICENSE)
- [microsoft/VFSForGit on GitHub](https://github.com/microsoft/VFSForGit)
- [README](https://github.com/microsoft/VFSForGit/blob/master/README.md)
- [Releases](https://github.com/microsoft/VFSForGit/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-vfsforgit