HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
microsoft
VFSForGit
C#2017–2025
microsoft / VFSForGit

VFSForGit

Virtual File System for Git: Enable Git at Enterprise Scale

48Distinct people
54Mentions
0Explicit recommenders
6.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Virtual File System for Git: Enable Git at Enterprise Scale

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 8:59:20 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year54 dated mentions

Observed mentions: 2017-02-03 11:08:08 UTC to 2025-10-22 19:47:37 UTC.

0510152017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 15 mentions; 5 submissions, 10 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 10 mentions; 0 submissions, 10 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC15510
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC10010
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC707
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC404
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC707
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC505
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC202
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
VFS for Git What is VFS for Git? VFS stands for Virtual File System. 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. VFS for Git also manages the files that Git will consider, to ensure that Git operations such as status, checkout, etc., can be as quick as possible because they will only consider the files that the user has accessed, not all files in the repository. Note: for new deployments, we strongly recommend you consider Scalar instead of VFS for Git. By combining the lessons from operating VFS for Git at scale with new developments in Git, Scalar offers a clearer path forward for all large monorepos. Installing VFS for Git VFS for Git requires Windows 10 Anniversary Update (Windows 10 version 1607) or later. To install, use winget to install the microsoft/git fork of Git and VFS for Git using: winget install --id Microsoft.Git winget install --id Microsoft.VFSforGit You will need to continue using the microsoft/git version of Git, and it will notify you when new versions are available. Building VFS for Git If you'd like to build your own VFS for Git Windows installer: Install Visual Studio 2022 Community Edition or higher (https://www.visualstudio.com/downloads/). Include the following workloads: .NET desktop development Desktop development with C++ Include the following additional components: Windows 10 or 11 SDK (10.0+) Install the .NET 10 SDK Install vcpkg (or use the copy bundled with Visual Studio's C++ workload) Create a folder to clone into, e.g. C:\Repos\VFSForGit Clone this repo into the src subfolder, e.g. C:\Repos\VFSForGit\src Run src\scripts\Build.bat (defaults to a Debug build) You can also build in Visual Studio by opening src\GVFS.sln (do not upgrade any projects) and building. However, the very first build will fail, and the second and subsequent builds will succeed. This is because the build requires a prebuild code generation step. For details, see the build script in the previous step. Visual Studio 2022 will automatically prompt you to install these dependencies when you open the solution. The .vsconfig file that is present in the root of the repository specifies all required components. The installer can now be found at C:\Repos\VFSForGit\out\GVFS.Installers\bin\[Debug|Release]\win-x64\SetupGVFS.<version>.exe AI coding assistants working in this repo: see AGENTS.md for project-specific build/test guidance. Trying out VFS for Git VFS for Git requires a Git service that supports the GVFS protocol. For example, you can create a repo in Azure DevOps, and push some contents to it. There are two constraints: Your repo must not enable any clean/smudge filters Your repo must have a .gitattributes file in the root that includes the line * -text gvfs clone <URL of repo you just created> Please choose the Clone with HTTPS option in the Clone Repository dialog in Azure Repos, not Clone with SSH. cd <root>\src Run Git commands as you normally would gvfs unmount when done Note on naming This project was formerly known as GVFS (Git Virtual File System). You may occasionally see collateral, including code and protocol names, which refer to the previous name. Licenses The VFS for Git source code in this repo is available under the MIT license. See License.md. VFS for Git relies on the PrjFlt filter driver, formerly known as the GvFlt filter driver, available as a prerelease NuGet package. VFS for Git also includes or links to third-party native libraries at build time. See THIRD-PARTY-NOTICES.md for details on these dependencies and their licenses.
Read the full README on GitHub

What Hacker News says

5 sources
> Are there some fundamental aspects of git that would make it either very difficult to improve that, or that would sacrifice some important benefits if they were made? I can't speak to improving git, but I think some light on this area can be shed by Linus' tech talk at Google in 2007. 1. Linus says there's a specific focus on full history and content, not files ... so it's a deliberate, different axis of focus than file count: https://youtu.be/4XpnKHJAok8?t=2586 ... AND it's a specific pitfall to avoid when using Git: https://youtu.be/4XpnKHJAok8?t=4047 2. As Linus tells it, Git appears to be designed specifically for project maintenance while not getting in the way of individual commits and collaboration. But the global history and more expensive operations on things like "who touched this line" are deliberate so lines of a function a
Read the rest
re tracked across all moves of the content itself. Maintainer tool enablement: https://youtu.be/4XpnKHJAok8?t=3815 Content tracking slower than file-based "who touched this": https://youtu.be/4XpnKHJAok8?t=4071 === I have no answer, but ... Practically, I've used lazy filesystems both for Windows-on-Git via GVFS [1][2] and Google's monorepo jacked into a mercurial client (I think that's what it is?). Both companies have made this work, but as Linus says, a lot of the stuff just doesn't work well with either system. Windows-on-Git still takes a lot of time overall, and stacking > 10 patches of an exploratory refactor with the monorepo on hg starts slowing WAY WAY down to the point where any source control operations just get in the way. [1] https://devblogs.microsoft.com/devops/announcing-gvfs-git-vi... [2] https://github.com/microsoft/VFSForGit
In We put half a million files in one Git repository (2022)
VFS for Git is still Open Source: https://github.com/microsoft/VFSForGit Microsoft's blog posts have indicated a move to use something as close to off-the-shelf git as possible, though. They say they've stopped using VFS much and are instead more often relying on sparse checkouts. They've upstreamed a lot of patches into git itself, and maintain their own git fork but the fork distance is generally shrinking as those patches upstream.
In We put half a million files in one Git repository (2022)

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.