Is partial clone a complete replacement of VFS for Git?

[Dragnalith]

Hello,

On the documentation of scalar it is said partial clone is a good replacement of VFS for Git. But in my understanding:

• partial clone download data on-demand when running a git command (e.g git checkout)
• but VFS for Git download data on-demand when accessing the file using OS API

So there is still a benefit of using VFS for Git compared to partial clone, in particular when you don't know in advance which file of your workspace you wanna access. Am I missing something?

[derrickstolee]

There are two aspects to VFS for Git that need replacement:

1. The "GVFS Protocol" reduces the amount of data required to clone the repository. Git's partial clone is the equivalent of this. It makes your git clone faster, but the trade-off is that you will need to download new objects when checking out a commit you have not previously checked out. There is some more work required to create the equivalent of a cache server for geo-replicated data (and to have it be auto-configured at clone time).

2. The virtualized filesystem reduces the amount of work for git checkout and related commands. The Git equivalent is the git sparse-checkout feature (to reduce the size of the working directory) plus the FS monitor feature (to help Git know what's changed).

If you install microsoft/git and run scalar clone <url>, then you are automatically set up with these features.

[Dragnalith]

Thank you Derrick for answering my question.

Isn't git-sparse-checkout an experience a bit different from the one offered by VFS for git?

• With git-sparse-checkout you have to manually configure what you want in you working directory
• With VFS for Git the working directory is "checkout and download" on-demand also the user can see what is available without any blob download

[derrickstolee]

Yes, sparse-checkout is different because you need to tell Git what you care about in advance.

This has advantages, such as allowing us to shrink the .git/index file. It also works better with other tools, such as opening VS Code at the src root (because it would hydrate all files as it crawls the filesystem). It also has fewer moving pieces that could cause confusing states that users need to do non-Git things to recover (such as gvfs unmount or gvfs repair).

Another benefit is that you can run git checkout and then go off-network. You know that you have everything you need to work at that location. With a virtual filesystem, you might have some missing objects that are waiting a filesystem access to trigger their download.

It is certainly easier to not worry about the sparse-checkout and just let the virtual filesystem figure it out. But really, that flexibility bites us more often than we'd like.

[Dragnalith]

Thank you, it's a very clear answer