Approaches to Virtualized Working Trees

Sparse-checkout says: "do not materialize everything." Partial clone says: "do not download everything up front." A virtualized or projected working tree pushes the idea further — present the namespace now, fetch file content only when something actually reads it.

This appendix is about what lives outside stock Git. Virtualized working trees are a design pattern implemented by external tools — VFS for Git, GVFS protocol extensions, projected filesystem drivers — not a feature you turn on with git config. The approach shaped Git's large-repo roadmap, and the built-in features (sparse-checkout, partial clone, prefetch, Scalar) now cover most of the motivating use cases. The underlying idea is still worth knowing, because it clarifies what the stock features are not doing.

The Core Idea

A projected working tree keeps the visible directory structure more complete than the bytes on disk. The filesystem layer presents placeholders for files that have not been hydrated; opening one triggers a fetch.

That changes the local contract:

• the user sees paths that are not fully local
• editors, builds, and watchers can trigger hydration just by touching a path
• "visible file" and "fully present local file" stop being the same thing

The benefit is startup cost. First clone, branch switch, and initial materialization get much cheaper because the filesystem view is cheap to present. The cost is hydration latency and variability at access time, and a working tree that does not behave quite like a normal one.

Where This Actually Runs

• VFS for Git (Windows): Microsoft's original projected-filesystem Git, built around Windows' ProjFS. Superseded internally by Scalar plus stock Git features. No longer actively developed.
• GVFS protocol extensions on servers: custom endpoints that serve object content on narrow demand. Not part of stock Git; hosts implement them if at all.
• Monorepo-specific systems: some large organizations maintain internal projected filesystems on top of FUSE or platform-specific projection APIs. These are bespoke and do not usually ship as a generic Git plugin.

Stock git does not ship a virtualized working tree. There is no git config core.projectedFilesystem. If you want this behavior today, you are either on VFS for Git (legacy), using an internal tool, or approximating with the stack of built-in features below.

The Built-In Stack Covers Most of the Same Ground

git clone --filter=blob:none --no-checkout <url> repo
cd repo
git sparse-checkout init --cone
git sparse-checkout set src docs
git checkout main

That sequence is not a projected filesystem. It is the concrete approximation stock Git offers:

• --filter=blob:none defers object content until needed
• --no-checkout plus sparse-checkout narrows what gets written to disk
• lazy fetch handles the "I suddenly need this blob" case

You can see the namespace-versus-materialization split with ordinary commands:

git ls-files --sparse | sed -n '1,20p'
git show HEAD:path/to/file | head
test -e path/to/file || echo not materialized

Git can enumerate tracked paths and read content from the repository without those paths being present as local files. A real projected filesystem pushes that split further down, into the filesystem view itself.

When the External Dependency Is Worth It

Virtualization pays off when:

• the repo is very large
• most users touch a small fraction of the tree
• the namespace itself matters for navigation and tooling
• local disk is constrained
• hydration is fast and reliable

It does not pay off when:

• tools eagerly crawl the whole tree anyway
• offline work matters
• hydration latency is unpredictable
• the repo is large but user access is broad

For most teams, the built-in stack (sparse-checkout, sparse-index, partial clone, Scalar, git maintenance, git backfill) covers the same pressure without a projected filesystem. Virtualization is still the right answer in a few places — mostly very large internal monorepos with skewed usage — but it is no longer the direction the ecosystem is moving.

The practical question for most readers is not "should I deploy a projected filesystem?" It is "how far can the built-in features take me before I would need one?" For most repos, further than you would think.