fix(cli): task-setup resolves repo via git-common-dir, not script cwd#899
Conversation
The script computed the target repo as $script_dir/.., which only works when invoked from the main checkout. Worktrees share the full working tree including scripts/, so running make task-setup NAME=foo from inside an existing worktree resolved repo to the calling worktree, not ~/Code/lobu. The new worktree then landed at <calling-worktree>/.claude/worktrees/foo/ — nested instead of flat at ~/Code/lobu/.claude/worktrees/foo/. Symptoms in practice: - make task-clean NAME=<outer> refusing because the outer dir contains another active worktree. - A FORCE=1 task-clean of the outer worktree clipping files inside the inner worktrees before bailing on Directory not empty. Fix: git rev-parse --git-common-dir returns the shared .git directory regardless of which worktree the call comes from. Its parent is the main checkout — the right answer for both worktree-add target and .env source.
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe script now resolves the repository root by querying Git's shared ChangesWorktree root resolution fix
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
…900) The previous fix (#899) called `git rev-parse --git-common-dir` without forcing absolute output. Without that, git returns a path relative to its cwd ("../.git"), and `dirname` of that resolves against whatever the caller's cwd happens to be — so running `make task-setup` from the main repo landed worktrees at /Users/burakemre/Code/.claude/worktrees/<name>/ (parent of the lobu checkout) instead of /Users/burakemre/Code/lobu/.claude/worktrees/<name>/. Fix: pass `--path-format=absolute` so git always returns the full path. `dirname` of an absolute /.../lobu/.git is reliably the main checkout. Verified by hand: from main: /Users/burakemre/Code/lobu from worktree: /Users/burakemre/Code/lobu
Summary
task-setup.shresolved the target repo as$script_dir/.., which only works when invoked from the main checkout. Worktrees share the full working tree includingscripts/, so runningmake task-setup NAME=foofrom inside an existing worktree landed the new worktree at<calling-worktree>/.claude/worktrees/foo/— nested — instead of~/Code/lobu/.claude/worktrees/foo/.Fix: resolve
repoviagit rev-parse --git-common-dir, which returns the shared.gitdirectory regardless of which worktree the call originates from. Its parent is always the main checkout.Reproducer
Before:
After:
Real-world fallout (from the session that uncovered it)
Two nested worktrees (
feat/frontendandfeat/landing-page) had been created via this bug from insidefeat/chrome-extension-e2e. Whenmake task-clean NAME=chrome-extension-e2e FORCE=1ran,rm -rfof the outer worktree clipped tracked files inside the inner worktrees before bailing on "Directory not empty". Tracked files were recoverable viagit checkout -- .; any untracked WIP would have been lost. This fix prevents the nesting from happening at all.Summary by CodeRabbit