[RFC] git worktree: use filesystem cloning where supported

[RFC] git worktree: use filesystem cloning where supported

[Peter Morris]

Hi,

I'd like to suggest a change to how git worktree creates files.

# Problem
git worktree add creates a new working tree containing copies of the
files from the existing working tree. This is normally fine, but it
can result in a lot of unnecessary data being written to disk.

This seems increasingly relevant with AI coding harnesses. These often
use Git worktrees to let multiple agents work on the same repository
concurrently. If several agents are working on a large repository,
each worktree can result in another copy of a large number of files
being written to the SSD.

SSD storage is expensive, and SSDs also have a limited write lifetime.
It seems wasteful to physically write the same data to disk several
times when the filesystem may be able to avoid doing so.

# Proposed solution
Where the filesystem supports copy-on-write or block cloning, could
git worktree use it when creating the working tree?

For example, Windows Dev Drives (which I use) support ReFS block
cloning. A file can be cloned without physically copying all of its
data, with the filesystem sharing the underlying blocks until one of
the files is modified.

If Git knows that the destination file will initially contain exactly
the same contents as the source file currently in the folder, it seems
like a good opportunity to use this facility.

The normal behaviour could remain unchanged on filesystems that don't
support this or when the existing file is modified or a different
version from the one that will be checked out.

# Why
This would potentially:

* reduce SSD writes when creating worktrees, extending my SSD lifespan
* reduce physical disk space used by multiple worktrees
* make creating worktrees faster for large repositories
* be particularly useful when AI agents are creating multiple
worktrees concurrently

I'm not suggesting that Git should become dependent on ReFS or any
particular filesystem. I'm wondering whether there is a suitable
abstraction for filesystem-level cloning, with
platform/filesystem-specific implementations where available.

I'd be interested to know whether this is something that would fit
with the future plans for Git, and whether there are technical reasons
why this couldn't work for worktrees?

Pete

Re: [RFC] git worktree: use filesystem cloning where supported

[Kristoffer Haugsbakk]

On Fri, Aug 14, 2026, at 12:40, Peter Morris wrote:
> I'd like to suggest a change to how git worktree creates files.
>
> # Problem
>[snip]

https://lore.kernel.org/git/pull.2317.git.git.1780685368.gitgitgadget@gmail.com/

Re: [RFC] git worktree: use filesystem cloning where supported

[Kristoffer Haugsbakk]

On Fri, Aug 14, 2026, at 13:12, Peter Morris wrote:
> The PR says it only supports Linux and macOS.
>
> ReFS is available on Windows too.
>
> I believe that if the source and destination are on the same ReFS
> volume, the Windows CopyFile API will use block cloning automatically,
> so if CopyFile were used we would get this for free on Windows Dev
> Drives.
>
>
>> [snip]
>> https://lore.kernel.org/git/pull.2317.git.git.1780685368.gitgitgadget@gmail.com/

You must remember to Reply-All here. Thanks. :)

Re: [RFC] git worktree: use filesystem cloning where supported

[Peter Morris]

The PR says it only supports Linux and macOS, but ReFS
is available on Windows too.

I believe that if the source and destination are on the same ReFS
volume the Windows CopyFile API will use block cloning automatically,
so if CopyFile were used we would get this for free on Windows Dev
Drives.

> [snip]
> Kristoffer Haugsbakk said:
> https://lore.kernel.org/git/pull.2317.git.git.1780685368.gitgitgadget@gmail.com/

Re: [RFC] git worktree: use filesystem cloning where supported

[Junio C Hamano]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

> On Fri, Aug 14, 2026, at 12:40, Peter Morris wrote:
>> I'd like to suggest a change to how git worktree creates files.
>>
>> # Problem
>>[snip]
>
> https://lore.kernel.org/git/pull.2317.git.git.1780685368.gitgitgadget@gmail.com/

In that thread, Brian makes a good point that you cannot "copy"
dirty working tree files from an existing worktree, and also that
you cannot have the same branch checked out in multiple worktrees at
the same time, to avoid making other worktrees out of sync when a
commit is made in one of the worktrees to advance the branch tip.

But these issues only mean that you cannot call it done by just
creating an identical CoW clone of the whole directory.  As long as
you are willing to accept that, instead of CoW-copying all existing
working tree files, you may have to give the new worktree its own
copy of the path by writing unique contents yourself, the above two
are surmountable.

However, when creating a new worktree, what happens is we check out
the working tree files for the new worktree from the index.  The
code paths doing the work to materialize these files on the
filesystem do not have any visibility into what _other_ worktrees,
including the original, have checked out in their working tree.

If anybody wants to work on this, first you'd need to stop thinking
about "there are many unchanged files already checked out in this
worktree so why not CoW copy them?"  Instead, you'd need to think at
the level of the checkout_entry() helper function and devise a way
to teach it not to do its thing, and instead do your CoW thing.

Roughly speaking, checkout_entry() takes an index entry that
records filetype (regular, executable, or symlink) and blob object
name, and the path to store the blob contents in.  It takes the
contents of the blob from the object database and writes them out
to the working tree.  Your enhancement to the system may go like
this:

 - First, iterate over the linked (non-bare) worktrees, examine the
   index of each of them, and make a mapping from each blob object
   to files in the working trees that have clean checkouts (there
   may be more than one such file that has a clean checkout of the
   same blob object).  Make sure you do not include any files with
   local modifications.

 - Hook into checkout_entry() to look at the mapping you created
   above.  When you notice that checkout_entry() is trying to check
   out a blob object known to your mapping, instead of letting it
   write the blob contents out by calling write_entry(), intercept
   the request and do your favorite CoW thing.  Make sure that you
   do not lose the race where somebody else may have updated the
   working tree file you CoW from since you made the above mapping
   while excluding locally modified files.

The TOCTOU issue may turn out to be nasty.  The cleanest way I can
think of to solve it is to hash the resulting file after making the
CoW copy to verify that what you CoW'ed was a good copy against your
index.  I personally am not interested in making such a change to
the system myself, mostly because of this.

If you hook into checkout_entry(), it will be used not only by
"git worktree add".  Anything that goes through checkout_entry(),
which is practically everything in Git that updates files in the
working tree with what is in the object database, will learn to
CoW-borrow from an existing checkout elsewhere in sibling worktrees.

HTH.