How it works, and what it promises.

The numbers

What one worktree of the Linux kernel costs.

The same repository, the same command, run twice. The only thing that changes is how much disk the filesystem has to hand out.

How it works

Where your new worktree gets its files.

Four steps. Git still performs the ones that decide what ends up in your worktree.

Compatibility

You should not be able to tell the difference.

Every item below is checked on every commit, by a suite that performs each operation twice — once through real git worktree add, once through git-sprout — and compares the results. It runs 28 repository fixtures across 41 argument shapes on macOS, Linux (btrfs, XFS, ext4) and Windows (NTFS, ReFS), plus the Linux kernel on two filesystems, and earns its authority by detecting 19 deliberately injected differences and finding none when git is compared against itself.

Coding agents and CI

If you run coding agents, you are already paying for this.

Coding agents create an isolated worktree per background session or task. Claude Code shells out to a plain git worktree add and locks the result; the harnesses and worktree managers people build on top do the same, because a worktree is the standard way to give an agent a tree it can break without touching yours.

git -c core.fsmonitor= worktree add --no-track -B <branch> <path> <sha>

That changes the shape of the disk math. One engineer running several agents in parallel on a monorepo allocates a fresh 1.8 GB per agent per task, and those worktrees are created and destroyed all day. On a CI or agent fleet it stops being a laptop annoyance and becomes a provisioning line item.

Because the shim sits in front of git rather than in front of any particular tool, every harness gets this without knowing git-sprout exists: no plugin, no integration, no configuration inside the agent. The parity promise is what makes that safe: anything that intercepts git for an unattended session has to be indistinguishable from git.

Install

One command.

Or cargo install git-sprout, or a binary from the releases page.

git sprout add ../myrepo-feature -b feature     # or: git worktree-fast add

Two things have to be true. The filesystem needs block cloning: APFS on macOS; btrfs, XFS with reflinks, or bcachefs on Linux; a ReFS volume or a Windows 11 Dev Drive on Windows. Everywhere else, ext4 and NTFS included, it runs plain git worktree add.

And the repository has to be one that does not convert files on checkout, because a file can only be shared when checking it out would not rewrite its bytes. Git for Windows turns core.autocrlf on by default, and with that setting there is nothing to share, so on a typical Windows repository sprout passes straight through to git worktree add. The same goes for * text=auto eol=crlf on any platform. Repositories with no conversion attributes clone everything, which is the common case on macOS and Linux, the kernel included.

Make it automatic

There is no git setting that can redirect git worktree add.

Both were tested rather than assumed. Git ignores an alias that shadows a builtin, and builtins never go through GIT_EXEC_PATH or PATH. So there are exactly two ways to make every worktree on a machine cheaper, and both are things you install deliberately.

1. A shell function, for what you type yourself

Each block rewrites git worktree add and passes everything else through untouched. It only affects the interactive shell.

git() {
  if [ "${1:-}" = worktree ] && [ "${2:-}" = add ]; then
    shift 2
    command git sprout add "$@"
  else
    command git "$@"
  fi
}

function git
    if test (count $argv) -ge 2; and test "$argv[1]" = worktree; and test "$argv[2]" = add
        command git sprout add $argv[3..]
    else
        command git $argv
    end
end

function git {
    $real = (Get-Command git -CommandType Application | Select-Object -First 1).Source
    if ($args.Count -ge 2 -and $args[0] -eq 'worktree' -and $args[1] -eq 'add') {
        $rest = @($args | Select-Object -Skip 2)
        & $real sprout add @rest
    } else {
        & $real @args
    }
}

def --wrapped git [...args] {
    if ($args | length) >= 2 and $args.0 == "worktree" and $args.1 == "add" {
        ^git sprout add ...($args | skip 2)
    } else {
        ^git ...$args
    }
}

The bash, zsh, fish and nushell blocks were executed against a real git before this page went up. The PowerShell one was reviewed line by line but has not been run on any machine yet, so treat it as unverified and say so if it misbehaves.

Each one matches only worktree add as the first two words. git -C dir worktree add, and anything else a script or an editor runs, goes to git untouched. That is what the shim below is for.

2. A git shim on PATH, for everything else

Editors, worktree managers, CI jobs and agent harnesses spawn git themselves, so a shell function never sees them. The shim is a small git wrapper in its own directory that you put ahead of the real git on PATH; it rewrites worktree add and passes every other command straight through to the real git.

git sprout install-shim      # prints the directory it wrote and the PATH line to add
git sprout uninstall-shim    # removes it

brew install never does this on its own. A wrapper in front of git is yours to opt into, and one command to undo.

If you already use a worktree manager, this makes it cheaper without changing anything about it: the shim is in front of git, not in front of your tools.