[Feature]: configurable worktree location

[danielo515]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

Hello. I currently have some requirements on some of my projects that doesn't allow me to put them in arbitrary locations. For example, the current location of the worktrees. I want them to be children of the main project folder so I can take advantage of all my local tools configured for that particular folder.

Proposed solution

I want a setting that I can adjust per project to tell where to create the worktrees, either in a global place or as children of the current worktree.

Why this matters

As I said I use tools that are folder-dependent to handle my available dependencies, and they will not be available if you put the worktree in some random place.

Smallest useful scope

All the people using direnv and flakes on parent directories and similar stuff

Alternatives considered

NOt using worktrees

Risks or tradeoffs

This will be backwards compatible

Examples or references

No response

Contribution

• I would be open to helping implement this.

[mhabegger]

This would be very helpful especially on Windows because of two reasons:

1. The dev drive usually runs ReFS and not NTFS, which is for small files. https://learn.microsoft.com/en-us/windows/dev-drive/
2. From company policy and attack surface reduction: the D-drive for depth is usually excluded from live scanning, https://learn.microsoft.com/en-us/defender-endpoint/microsoft-defender-endpoint-antivirus-performance-mode

[juliusmarminge]

#6975 proposes the same per-project worktree location with a literal path. It adds useful constraints: apply the setting server-side to desktop, mobile and PR-created threads, and allow the configured root in review/diff validation. Existing worktrees need not move.

[murbanowicz]

I had a go at this — #9681.

Follows the constraints @juliusmarminge listed: the root is resolved server-side, so new worktree threads, PRs opened as threads and mobile all land in the same place, and existing worktrees stay where they are. One difference worth flagging — for review/diff validation I ended up authorizing the worktree path each thread recorded rather than the project's current configured root. Same effect, but it keeps working after you change the setting, and it avoids a root like / authorizing everything.

@danielo515 your case works: set it to /path/to/myrepo/.worktrees and branches land at .worktrees/<branch>, so direnv walking up from there finds the .envrc in your main checkout. Worth gitignoring .worktrees/ so it doesn't show up as untracked. The one limitation is that the path has to be absolute — there's no way to say "relative to this project" yet. It's stored per checkout, so an absolute path is fine per machine, but if ./.worktrees is what you actually wanted, that'd be a follow-up.

@mhabegger Windows drive and UNC paths work, and a root the hosting server can't read as absolute is ignored rather than resolved somewhere unexpected.

First time contributing here so I'm not sure how you prefer to handle this — CONTRIBUTING says to discuss non-trivial changes first, which is why I'm posting rather than just leaving the PR sitting. CI also hasn't run on it; looks like it needs a maintainer to approve workflows for a first-time contributor. No expectations either way — happy for it to sit, or be closed if it's not a direction you want.

[danielo515]

The one limitation is that the path has to be absolute — there's no way to say "relative to this project" yet. It's stored per checkout, so an absolute path is fine per machine, but if ./.worktrees is what you actually wanted, that'd be a follow-up.

Where is that config stored? My main limitation is that I don't want 55 config files of each of the tools I'm trying. Relative path should be doable by quering git for the main folder of the repository. worktrunk does it that way

[murbanowicz]

@juliusmarminge — #9681 is rebased on current main and mergeable, if you ever want to look. It implements the constraints you listed here.

CI hasn't run on it, so there's nothing green to judge it by — it needs the workflow approval first-time contributors need. Genuinely no pressure either way; happy to close it if it's not wanted.