[Feature Request] Use ReFS block cloning for Git worktrees #6423

Git worktrees already share the Git object database, but each worktree still contains a separate physical copy of all checked-out files.

On Windows, when the repository is located on an ReFS volume, Git could potentially use ReFS block cloning (FSCTL_DUPLICATE_EXTENTS_TO_FILE) to reduce the disk space occupied by multiple worktrees.

For example, when creating a new worktree:

repo-main/
    src/...
    large-file.bin

repo-feature-a/
    src/...
    large-file.bin

repo-feature-b/
    src/...
    large-file.bin

If the files correspond to the same Git blobs, their contents are known to be identical. Instead of writing another physical copy, Git could clone the extents from an existing worktree when possible.

ReFS would then use copy-on-write semantics if one of the files is subsequently modified.

This could significantly reduce disk usage for developers working with large repositories and many worktrees, while remaining transparent to Git and applications accessing the working tree.

Git LFS already uses ReFS block cloning on Windows via FSCTL_DUPLICATE_EXTENTS_TO_FILE, so there appears to be an existing precedent for using this ReFS capability in the Git ecosystem.

The optimization could be opportunistic:

Detect that the target filesystem supports block cloning.
When checking out a blob that is already present and unchanged in another worktree, use that file as the source for a block clone.
Fall back to the normal checkout path when block cloning is unavailable or fails.

I realize that locating an appropriate source file in another worktree adds complexity and that the Git object itself cannot necessarily be used directly because it may be compressed or stored inside a packfile.

However, git worktree seems like a particularly good use case because Git already knows about the other worktrees and their checked-out commits.

Would using ReFS block cloning as an optional optimization for git worktree add be feasible?

N/A

git worktree add