d36514b816
* test(#4758): failing-first — rescue must resolve a relative worktree_path against repoRoot * fix(#4758): rescue resolves a relative worktree_path against repoRoot, not process.cwd() * test(#4758): review fold-ins — t.after cleanup pattern, post-resolution reader contract comment * chore(#4758): changeset fragment * chore(#4758): backfill changeset PR number (4872) * test(#4758): windows lanes key rescue fakes on resolved path identity, not verbatim strings win32 path.resolve rewrites driveless-absolute POSIX-style fixture values to the current drive, so the rescue's (correct) resolved-path handoff stopped matching verbatim string keys: #3804/#245/#2556/B7/#2852 fakes silently skipped the rescue and my seam test compared against a POSIX literal. Fakes now key on path.resolve(repoRoot, …) identity — the same semantics the code and git -C use — so every rescue test exercises the rescue on every platform. --------- Co-authored-by: sim <sim@local>
442 B
442 B
type, pr
| type | pr |
|---|---|
| Fixed | 4872 |
Worktree cleanup-wave rescues SUMMARY artifacts from relative worktree paths — a manifest entry carrying a relative worktree_path made the rescue walk the CLI's working directory instead of the repo root, finding nothing and blocking the entry worktree_dirty instead of rescuing; the rescue now resolves the path against the repo root, the same way every git consumer of the field already does. (#4758)