Please talk more about the benefits about vfsforgit HOT 1 CLOSED

That is a great question, and one that we will work to give more specific guidance on. Some general thoughts...

You're absolutely right that there's no need to virtualize smaller repos. In general, if you're going to need most/all of the contents of a repo, doing a bulk copy of all of the contents is MUCH faster than copying each file one at a time. So even for larger repos, the same holds: if you're going to use all of the files, e.g. because you will build from the root and the build touches everything, then again you lose much of the benefits of virtualizing.

Based on our own experience within Microsoft, I can tell you that if your codebase is roughly 100K files or fewer, and less than single digit GBs of content, Git works pretty well as is, especially with some of the more recent perf improvements that have been made there.

If your codebase is 1M files or more, then chances are that you have a sophisticated build infrastructure as well, and that most of your devs don't build all of the sources themselves. The most common workflow on teams of that size is that devs download the build outputs from the most recent official build, and then run an incremental build on some subfolder that contains the sources they are working in.

If you fit both of those conditions: 1) You have lots of source files (I'd guess 250K or more? 500K or more?) and 2) devs don't need to access every file in their day to day work; then you might benefit from virtualizing.

GVFS provides two important functions: one is that it helps you avoid downloading file contents that you don't need. The other is that it manages the specific set of files that Git has to consider when you run commands like "git status", "git checkout", etc. So we're tackling both the problem of size, but also the problem of too many files.

from vfsforgit.