add configurable worktree location settings#1926
add configurable worktree location settings#1926tarik02 wants to merge 2 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
Medium Risk
Changes how worktree paths are chosen across server and WS RPC flows, and introduces new settings-driven path templating/validation that could affect where repos are created on disk.
Overview
Adds a new server setting (
worktreeLocation) that lets users choose where git worktrees are created (default global layout, project-subdirectory, project-sibling, or a validated custom absolute-path template), with a live preview + inline validation in the General Settings UI.Introduces shared
@t3tools/shared/worktreeLocationhelpers for sanitization, template validation/substitution, and preview rendering, plus a new server-sideWorktreeLocationResolverservice/layer that resolves the final create-worktree path fromServerConfig+ServerSettings.Updates server worktree creation flows (
GitManager.preparePullRequestThread, websocketgitCreateWorktree, and bootstrap worktree preparation) to resolve a concrete path before callingGitCore.createWorktree, and adjusts RPC/contracts error unions to includeWorktreeLocationResolverError. Also removesGitCore’s dependency onServerConfigand simplifies several test layers accordingly.Reviewed by Cursor Bugbot for commit ee02eec. 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 ee02eec. 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 ]