add configurable worktree location settings#1926
add configurable worktree location settings#1926tarik02 wants to merge 3 commits intopingdotgg:mainfrom
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
bot
added
size:XL
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
| return segments.at(-1) ?? input; | ||
| } | ||
|
|
||
| function getPathDirname(input: string): string { |
There was a problem hiding this comment.
🟢 Low src/worktreeLocation.ts:76
getPathDirname returns "C:" for path C:\foo, but C: in Windows refers to the current working directory on that drive, not the root directory C:\. This causes $PROJECT_DIRNAME to resolve to a semantically incorrect path when projects are located at a Windows drive root.
🤖 Copy this AI Prompt to have your agent fix this:
In file packages/shared/src/worktreeLocation.ts around line 76:
`getPathDirname` returns `"C:"` for path `C:\foo`, but `C:` in Windows refers to the current working directory on that drive, not the root directory `C:\`. This causes `$PROJECT_DIRNAME` to resolve to a semantically incorrect path when projects are located at a Windows drive root.
Evidence trail:
1. packages/shared/src/worktreeLocation.ts lines 76-92 - `getPathDirname` function implementation shows `trimmed.slice(0, separatorIndex)` returns `"C:"` for input `C:\foo`
2. packages/shared/src/worktreeLocation.ts lines 54-59 - `trimTrailingSeparators` function confirms input "C:\foo" passes through unchanged
3. https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats - Microsoft documentation confirms `C:` is a relative path to current directory on drive C, while `C:\` is the root. States this difference is "a common source of bugs that involve Windows file paths."
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit ee02eec. Configure here.
| const TRAILING_SEPARATOR_PATTERN = /[\\/]+$/; | ||
| const LEADING_SEPARATOR_PATTERN = /^[\\/]+/; | ||
| const ABSOLUTE_TEMPLATE_VARIABLE_PREFIXES = ["$T3_HOME", "$PROJECT_DIRNAME"] as const; | ||
| const ABSOLUTE_TEMPLATE_VARIABLES = ["$T3_HOME", "$PROJECT_DIRNAME"] as const; |
There was a problem hiding this comment.
Redundant identical constant arrays for template variables
Low Severity
ABSOLUTE_TEMPLATE_VARIABLE_PREFIXES and ABSOLUTE_TEMPLATE_VARIABLES are two separate const arrays with identical contents (["$T3_HOME", "$PROJECT_DIRNAME"]). They're used in startsWithAbsoluteTemplatePrefix and validateWorktreeLocationTemplate respectively, but serve the same conceptual purpose of identifying absolute-path template variables. A single constant would be clearer and avoid the risk of them diverging silently in a future edit.
Reviewed by Cursor Bugbot for commit ee02eec. Configure here.
ApprovabilityVerdict: Needs human review This PR introduces a new user-facing feature with configurable worktree location settings, including new settings schema, a new service layer, new UI controls, and template validation logic. The scope and runtime behavior changes warrant human review even though individual components appear well-structured. You can customize Macroscope's approvability policy. Learn more. |
1 participant
Fixes #1878
What Changed
This adds configurable worktree location settings so T3 Code does not have to create worktrees in one fixed global layout.
Specifically, this PR:
Why
Some projects depend on folder-scoped local tooling and parent-directory configuration.
Examples from the issue include setups like
direnv, flakes, and similar tooling that only work when the worktree lives under the expected project directory tree. The current global worktree location breaks those setups because the new worktree ends up outside the folder hierarchy those tools rely on.This change lets users keep the existing global behavior, place worktrees under the project, or define a custom layout when their environment has stricter path requirements.
UI Changes
Before:
After:
Worktree locationsetting_20260411_131122.webm
Checklist
Note
High Risk
Medium-to-high risk because it changes how/where git worktrees are created across
GitManagerand WS RPC flows, and introduces a new resolver with a likely bug (yield*on a non-Effect error object) that could break worktree creation at runtime.Overview
Adds configurable worktree location settings (mode + optional custom template) and a new
WorktreeLocationResolverservice to compute worktree paths from server settings, with shared validation/substitution/preview logic in@t3tools/shared/worktreeLocation.Updates server worktree-creation call sites (
GitManager.preparePullRequestThread, WSgitCreateWorktree, and bootstrap worktree preparation) to resolve an explicit worktree path before callingGitCore.createWorktree, and removesGitCore's dependency onServerConfigby requiring callers to supplypath.Adds UI controls in
GeneralSettingsPanelto select the worktree location mode, edit/reset a custom template with live preview + inline validation, and extends RPC/contracts to includeWorktreeLocationResolverError(notablyWsGitCreateWorktreeRpccan now return it).Reviewed by Cursor Bugbot for commit 8b51481. Bugbot is set up for automated code reviews on this repo. Configure here.
Note
Add configurable worktree location settings with mode selection and custom templates
WorktreeLocationResolver, a new service that computes worktree paths from server settings supporting four modes: default, project-subdirectory, project-sibling, and custom template.WorktreeLocationSettingsto the server settings schema with a mode and optional custom template field; settings can be patched and restored to defaults.GitCoreintoGitManagerand the WebSocket RPC layer; callers must now supply an explicit path tocreateWorktree.GeneralSettingsPanelwith live path preview, inline template validation, and reset-to-defaults support.worktreeLocation.tshelper module, used by both server and web.WsGitCreateWorktreeRpccan now return aWorktreeLocationResolverError; existing callers that do not supply a path will have it resolved dynamically.📊 Macroscope summarized 8b51481. 20 files reviewed, 2 issues evaluated, 1 issue filtered, 1 comment posted
🗂️ Filtered Issues
apps/server/src/project/Layers/WorktreeLocationResolver.ts — 0 comments posted, 1 evaluated, 1 filtered
yield*is used on a plainWorktreeLocationResolverErrorobject returned bycreateWorktreeLocationResolverError(). Since this function returns an error object (not anEffect), usingyield*on it will fail at runtime because the error class is not an Effect/Yieldable. The code should useEffect.fail()to properly fail with this error:return yield* Effect.fail(createWorktreeLocationResolverError(...))[ Failed validation ]