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, 6:01:08 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

15 sources
Not explicitly, IFAIK the main slowness/limits you risk hitting are: 1. Git clones are deep and wide by default, so you end up with local repos that are the size of the total history. (easy to work around) 2. Git narrow clone support isn't the greatest, so you will probably want to fit the "working directory" on one computer. (somewhat painful to work around) 3. Git has to checkout all files every time you change branches which can be slow if you have a large working directory. (very painful) 4. Many operations (status, diff, commit for example) require git to scan the working directory to see what changed. This will be very slow if you have many files in your working directory. (very painful) Luckily all of these problems can be solved seamlessly with a virtual filesystem approach. For example https://github.com/Microsoft/GVFS
In Mercurial with Largefiles: Why it is not a solution for game development
yeah this was really confusing in the article everywhere it mentions up-streaming it refers to "git" only then later mentions how GitHub is accepting it's modifications... so not entirely sure which it is. TL;DR pretty sure it's not touching git source at all. Looking though the GVFS readme: https://github.com/Microsoft/GVFS it appears that it actually wraps git, which would make sense because in that case they would have to explicitly add support to each git host and provide individual platform ports of GVFS (all of which would be unnecessary if it was actually upstreamed into git). So that's good... git is one of my favourite open source tools and I would really hate for M$ to start polluting it. I don't care if GVFS is a good idea or not I just don't trust the fuckers and they will always deserve that suspicion.
In Microsoft and GitHub team up to take Git virtual file system to macOS, Linux
In the reference implementation from Microsoft it most closely resembles a CDN: you give it a list of servers to back the git database when it needs to look up an object. You distribute those servers as you see need to, based on very similar logic to CDN distribution. For instance, you probably want at least one available per office to keep content close to the users that need it. Even if a CDN is more "hierarchical" rather than P2P, it's still distributed, it's just distributed on a different axis than you are perhaps expecting. Furthermore, to a very large extent that's an implementation detail. The GVFS protocol itself [1] is a very simple REST API, and there is absolutely nothing stopping you from building a GVFS "server" that is literally backed by IPFS or BitTorrent or some other P2P file system. [1] https://github.com/Microsoft/gvf
Read the rest
In Microsoft and GitHub team up to take Git virtual file system to macOS, Linux

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.