Separate git dir: {{ repo_path }} resolves to the git directory's parent, not the work tree

[zengzheqing]

Summary

With a repository whose git directory lives outside the work tree (git init --separate-git-dir <store>, so .git is a file pointing at <store>), wt switch --create resolves {{ repo_path }} to the parent of the git directory, not to the work tree. The new worktree is created next to the store, and wt list shows the main worktree's path as the store as well.

Repro (wt v0.79.0, macOS, clean HOME with no user config)

mkdir -p repro/store repro/work repro/home
git init --separate-git-dir "$PWD/repro/store/repo.gitdir" repro/work
git -C repro/work commit -q --allow-empty -m init
cd repro/work
HOME="$PWD/../home" wt switch --create probe --no-cd --format=json

Output:

{"action":"created","branch":"probe","path":"<…>/repro/store.probe","created_branch":true,"base_branch":"main"}

Expected path is <…>/repro/work.probe (a sibling of the work tree, per the default {{ repo_path }}.{{ branch }} template).

wt list in the same state:

  Branch  Status  …  Path            Commit    Age  Message
^ main    ·  ·^      .               562ed3b   now  init
+ probe       _      ../store.probe  562ed3b   now  init

Likely cause

git worktree list itself reports the git directory as the main worktree entry in this layout:

<…>/repro/store/repo.gitdir 562ed3b [main]
<…>/repro/store.probe       562ed3b [probe]

so anything deriving the repo path from that first line lands on the store. Running git worktree repair (which writes the <store>/gitdir backlink, content <…>/repro/work/.git) does not change the result: a second wt switch --create probe2 still lands at <…>/repro/store.probe2.

Two sources that do give the work tree in this layout: git rev-parse --show-toplevel run from the main work tree, or the <gitdir>/gitdir backlink file (present after git worktree repair, absent right after git init --separate-git-dir).

Workaround

A per-project entry with an absolute worktree-path in the user config avoids the wrong placement, but wt list still shows the store as the main worktree's path.

Environment

• wt v0.79.0 (also the latest release as of 2026-09-21)
• git 2.x, macOS 26
• 7 repositories on this machine use this layout (git dir kept outside a cloud-synced folder); all reproduce.

[zengzheqing]

One more data point from the same layout: wt remove <branch> run from the main work tree fails outright, while wt switch --create succeeds (with the wrong path):

$ cd <work tree with .git file>
$ wt remove probe --yes
  fatal: not a git repository (or any of the parent directories): .git

Same repository state as above (a per-project absolute worktree-path in the user config, so the worktree itself was created inside the work tree). git worktree remove --force <path> works, so it looks like remove runs git from the resolved repo path (the store's parent) rather than from the work tree.

[worktrunk-bot]

Reproduced both symptoms, and your diagnosis was right: repo_path() resolved a non-bare repository to the parent of the git common dir, which is the work tree only when the git directory sits inside it. #4236 makes it read the gitdir backlink git keeps next to the store instead. That one change covers all three surfaces — worktree placement via {{ repo_path }}, the main worktree's path in wt list, and the wt remove failure in your follow-up, which died because it ran git from the store's parent and that directory is not a repository at all.

One caveat worth knowing before the fix lands, because it decides whether it helps your 7 repositories directly. Only git worktree repair writes that backlink — git init --separate-git-dir and git clone --separate-git-dir leave the store without one, so a repository that has never been repaired still records its work tree nowhere for wt to find. You already observed that repair changes nothing today; with #4236 it becomes the remedy, so running git worktree repair once in each work tree is what will switch those repositories over. A freshly created one still lands on the old wrong path until it is run.

Closing that remaining gap needs a call I did not want to make unilaterally, and I have described the options in the PR: the work tree is derivable from where wt was invoked, but only in the main work tree, so relying on it would make {{ repo_path }} depend on the invocation directory; the alternatives are having wt write the backlink itself or cache the work tree in git config, both of which put a write on a read path. A maintainer should pick.

Verified behavior, before and after

Against your repro, with the branch built:

# before `git worktree repair` — unchanged
{"action":"created","branch":"probe","path":".../store.probe",...}
$ wt remove probe --yes
✗ git rev-parse --git-common-dir failed (exit 128)
  fatal: not a git repository (or any of the parent directories): .git

# after `git worktree repair`
{"action":"created","branch":"probe2","path":".../work.probe2",...}
$ wt remove probe --yes
◎ Removing probe worktree & branch in background

wt list then shows the main worktree as . rather than the store.

#4236 still needs maintainer review before it lands, and its Windows test leg was still running when I wrote this; Linux and macOS are green.

[zengzheqing]

Thanks, that matches what I saw. Data point for the caveat: all 7 repositories here already carry the <store>/gitdir backlink (each was passed through git worktree repair when the store was moved out), so #4236 as written covers them without a further step. Reading the backlink and confirming it round-trips is the behaviour I would have expected; the first-run gap for a never-repaired store seems fair to leave to a maintainer's call.

[worktrunk-bot]

Good — that settles it for your case, and the round trip is what #4236 does: it reads <store>/gitdir, then reads the .git entry at the work tree that names, and accepts the path only if it points back at the same common dir. A backlink left by a work tree that has since moved or been re-pointed falls through to the old parent(git_common_dir) answer rather than to a path that no longer holds the repository.

CI has since gone green on all three legs (Linux, macOS, Windows) plus codecov/patch, so the PR is just waiting on maintainer review now — including the first-run call, which stays open as you say.