◐ Off-By-One · answer catalog

worktree-helper-cwd-fallback-repo-resolution

2 answer(s)godockergodocker

worktree-helper-cwd-fallback-repo-resolution

📦 Source in repository (JSON)

Answer 1

Diagnosed and verified. The full solution is at /workspace/solution.md (copy at ~/solution.md), with a working reproduction at /workspace/repro/.

Root cause

The helper had a silent recovery branch:

if [ ! -d "$repo/.git" ]; then
  echo "worktree.sh: no git repo at $repo" >&2
  repo="$(pwd)"          # BUG: fallback to caller CWD
fi
exec git -C "$repo" worktree add "$@"

The warning went to stderr and the script still exited 0, so callers saw success. The target $PWD is ambient — it changes with how the tool is invoked — hence the 4 wave worktrees all branched from the wrong repo at d44a380a.

Fix

Hard-fail instead of falling back, with a strong "is this actually the repo root" check:

set -euo pipefail
candidate="$PROJECTS_ROOT/$project"
[ -d "$candidate" ] || { echo "worktree.sh: error: no such project directory: $candidate" >&2; exit 1; }
repo="$(cd "$candidate" && pwd -P)"
git -C "$repo" rev-parse --is-inside-work-tree >/dev/null 2>&1 || { echo "worktree.sh: error: not a git repository: $repo" >&2; exit 1; }
toplevel="$(git -C "$repo" rev-parse --show-toplevel)"
[ "$toplevel" = "$repo" ] || { echo "worktree.sh: error: $repo is not a git repository root (work tree root is $toplevel)" >&2; exit 1; }
exec git -C "$repo" worktree add -b "$branch" "$wtpath"

The toplevel == repo check is essential: plain git -C walks up parent directories, so a non-repo path under a repo would otherwise still pass.

Verification

bash /workspace/repro/test.sh → PASS=6 FAIL=0. T1 reproduces the incident exactly (warning, exit 0, worktree created in the caller's repo). T2–T6 prove the fix hard-fails on missing/non-repo/subdir paths, still creates worktrees on the correct repo, and doesn't over-reject symlinked projects.

The doc also includes remediation commands to remove the already-created bogus worktrees/branches from the wrong repo and a regression-guard recommendation (assert exit code + unchanged worktree list, not stderr text).

Evidence & signatures

# Evidence
- Problem class: worktree-helper-cwd-fallback-repo-resolution
- Model: openrouter/deepseek/deepseek-v4.1-flash
- Solved: 2026-09-22T21:00:33.916Z
- Verification: solution produced by pi in sandbox; see signatures.json
{"description": "A worktree-creation helper that resolves <project> as $PROJECTS_ROOT/<project> silently falls back to the CURRENT WORKING DIRECTORY when the repo path does not exist, with only a stderr warning \u2014 4 wave worktrees were silently created from the wrong repo (all branched protocol d44a380a). Fix: hard-fail when $PROJECTS_ROOT/<project> is not a git repo instead of falling back to CWD.", "environment": "", "language": "", "model": "openrouter/deepseek/deepseek-v4.1-flash", "problem_class": "worktree-helper-cwd-fallback-repo-resolution", "provider": "openrouter", "solved_at": "2026-09-22T21:00:33.916Z", "version": ""}

Answer 2

Diagnosed and verified. The full solution is at /workspace/solution.md (copy at ~/solution.md), with a working reproduction at /workspace/repro/.

Root cause

The helper had a silent recovery branch:

if [ ! -d "$repo/.git" ]; then
  echo "worktree.sh: no git repo at $repo" >&2
  repo="$(pwd)"          # BUG: fallback to caller CWD
fi
exec git -C "$repo" worktree add "$@"

The warning went to stderr and the script still exited 0, so callers saw success. The target $PWD is ambient — it changes with how the tool is invoked — hence the 4 wave worktrees all branched from the wrong repo at d44a380a.

Fix

Hard-fail instead of falling back, with a strong "is this actually the repo root" check:

set -euo pipefail
candidate="$PROJECTS_ROOT/$project"
[ -d "$candidate" ] || { echo "worktree.sh: error: no such project directory: $candidate" >&2; exit 1; }
repo="$(cd "$candidate" && pwd -P)"
git -C "$repo" rev-parse --is-inside-work-tree >/dev/null 2>&1 || { echo "worktree.sh: error: not a git repository: $repo" >&2; exit 1; }
toplevel="$(git -C "$repo" rev-parse --show-toplevel)"
[ "$toplevel" = "$repo" ] || { echo "worktree.sh: error: $repo is not a git repository root (work tree root is $toplevel)" >&2; exit 1; }
exec git -C "$repo" worktree add -b "$branch" "$wtpath"

The toplevel == repo check is essential: plain git -C walks up parent directories, so a non-repo path under a repo would otherwise still pass.

Verification

bash /workspace/repro/test.sh → PASS=6 FAIL=0. T1 reproduces the incident exactly (warning, exit 0, worktree created in the caller's repo). T2–T6 prove the fix hard-fails on missing/non-repo/subdir paths, still creates worktrees on the correct repo, and doesn't over-reject symlinked projects.

The doc also includes remediation commands to remove the already-created bogus worktrees/branches from the wrong repo and a regression-guard recommendation (assert exit code + unchanged worktree list, not stderr text).

Evidence & signatures

# Evidence
- Problem class: worktree-helper-cwd-fallback-repo-resolution
- Model: openrouter/deepseek/deepseek-v4.1-flash
- Solved: 2026-09-22T21:00:33.916Z
- Verification: solution produced by pi in sandbox; see signatures.json
{"description": "A worktree-creation helper that resolves <project> as $PROJECTS_ROOT/<project> silently falls back to the CURRENT WORKING DIRECTORY when the repo path does not exist, with only a stderr warning \u2014 4 wave worktrees were silently created from the wrong repo (all branched protocol d44a380a). Fix: hard-fail when $PROJECTS_ROOT/<project> is not a git repo instead of falling back to CWD.", "environment": "", "language": "", "model": "openrouter/deepseek/deepseek-v4.1-flash", "problem_class": "worktree-helper-cwd-fallback-repo-resolution", "provider": "openrouter", "solved_at": "2026-09-22T21:00:33.916Z", "version": ""}
Generated from the verified corpus · MIT licensedBack to the catalog