Worktrees don't work when the worktree is created on Windows but used from WSL

[svick]

Existing issues matching what you're seeing

• I was not able to find an open or closed issue matching what I'm seeing

Git for Windows version

git version 2.53.0.windows.2
cpu: x86_64
built from commit: e9edee0b34751bf4d7d1feda0e2535bff64d4e77
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64/usr/bin/sh
rust: disabled
feature: fsmonitor--daemon
gettext: enabled
libcurl: 8.18.0
OpenSSL: OpenSSL 3.5.5 27 Jan 2026
zlib: 1.3.1
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1

Windows version

Windows 11

Windows CPU architecture

x86_64 (64-bit)

Additional Windows version information

Microsoft Windows [Version 10.0.26100.8246]

Options set during installation

Editor Option: VIM
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable FSMonitor: Disabled

Other interesting things

No response

Terminal/shell

powershell

Commands that trigger the issue

On Windows, I have created a worktree of the dotnet-runtime repo called dotnet-runtime-wsl:

C:\code\dotnet-runtime> git worktree add ..\dotnet-runtime-wsl HEAD

Then on WSL, I have attempted to use git from this worktree:

/mnt/c/code/dotnet-runtime-wsl$ git status

Expected behaviour

A Windows-created worktree works under WSL, just like a Windows-created repo does.

Actual behaviour

An error when I attempt to use the worktree on WSL, seemingly an issue with translating Windows paths to Linux paths.

/mnt/c/code/dotnet-runtime-wsl$ git status
fatal: not a git repository: /mnt/c/code/dotnet-runtime-wsl/C:/code/dotnet-runtime/.git/worktrees/dotnet-runtime-wsl

Repository

https://github.com/dotnet/runtime/, but this is almost certainly not repository-specific.

[dscho]

This is a known issue, and I have no idea whether this can be fixed. You see, the worktree mechanism has to store the path to the actual gitdir in its .git file, and this path can either be a WSL path or a Windows path, not both. But in your intended use case it would need to be both!

The only work-around I can think of is to call git with --git-dir=<correct-path-format> <command>.

But then you will face another problem. git status does not inspect every file's contents, it uses the stat() data to determine whether a file has been changed since its status was last checked (and cached in the Git index). This stat() data includes, but is not limited to, the mtime, the size, and the inode number. That inode number is distinctly different between Windows and WSL! As a consequence, git status cannot use any information in the Git index and has to re-scan all the files. And then it will store the information in the Git index, and when you then call Git "from the other side" (i.e. after running git status on Windows, running another git status in WSL, or vice versa), the same will happen again. Really poor performance is the consequence!

And it does not stop there. Sure, you can access Windows files from within WSL. But it will never be the same speed, not by a far stretch, as accessing WSL files from within WSL.

I have several personal use cases where I need to fetch/push between Windows and WSL. Accessing Git repositories (loose and packed objects, refs, etc) across the Windows <-> WSL boundary is so bad that I usually call git bundle create ... in one, and then git fetch /path/to/bundle in the other. That sounds convoluted, and it is, and at the same time it is still tons faster than the simple git fetch /path/to/other-repo.

In other words: Even if I had an idea how to implement your wish, it would still result in a poor user experience. For that reason, I would like to recommend: Don't do that. Use separate Git clones, even though that doubles disk space requirements.

[svick]

This is a known issue, and I have no idea whether this can be fixed. You see, the worktree mechanism has to store the path to the actual gitdir in its .git file, and this path can either be a WSL path or a Windows path, not both. But in your intended use case it would need to be both!

Does it have to be an absolute path (assuming both directories are on the same disk)? Because a relative path should work on both systems (as long as you use slash as directory separator on both, or somehow translate between the two).

But then you will face another problem. git status does not inspect every file's contents, it uses the stat() data to determine whether a file has been changed since its status was last checked (and cached in the Git index). This stat() data includes, but is not limited to, the mtime, the size, and the inode number. That inode number is distinctly different between Windows and WSL! As a consequence, git status cannot use any information in the Git index and has to re-scan all the files. And then it will store the information in the Git index, and when you then call Git "from the other side" (i.e. after running git status on Windows, running another git status in WSL, or vice versa), the same will happen again. Really poor performance is the consequence!

This data is specific to each worktree, right? Since I don't switch between systems much within a single worktree, this shouldn't be a problem.

[dscho]

Does it have to be an absolute path (assuming both directories are on the same disk)?

That's a big assumption. In general, it does not hold true.

But yes, it can be a relative path (if that is possible).

Though you still suffer the bad I/O performance even then. That's why this is a use case I do not plan to support.