Existing issues matching what you're seeing
Git for Windows version
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?Windows version
Windows 11
Windows CPU architecture
x86_64 (64-bit)
Additional Windows version information
Options set during installation
Other interesting things
No response
Terminal/shell
GitBash
Commands that trigger the issue
Expected behaviour
Clone ReFS block
Actual behaviour
File is physically duplicated
Repository
No response
Existing issues matching what you're seeing
Git for Windows version
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?Windows version
Windows 11
Windows CPU architecture
x86_64 (64-bit)
Additional Windows version information
Options set during installation
Other interesting things
No response
Terminal/shell
GitBash
Commands that trigger the issue
Expected behaviour
Clone ReFS block
Actual behaviour
File is physically duplicated
Repository
No response