44: Git worktree support for bare repos #150

david · 2026-08-01T11:45:46Z

david commented

2026-08-01 11:45:46 +00:00

44: Git worktree support for bare repos

Implements 44.

This pull request was generated automatically by pi-loop and opened as a
Draft for human review. Do not merge without reviewing the changes.

Generated in 1h 32m 48s.

Review findings

Now I have a complete understanding. Let me implement all fixes systematically.

All gates pass. Let me now output the final annotated findings document:

# Review Findings — 44

## Summary

Fixed 14 of 15 findings. All Critical and High findings (except batch mode worktree handling) have been resolved. Build, test, and lint gates all pass. The batch mode worktree handling finding remains unresolved as it requires significant refactoring of the batch runner to be properly addressed.

## Critical

- [x] src/cli/services/runCli.ts:893 — `resolveWorkDirForIssue` is called but never defined anywhere in the codebase. The diff adds `resolveWorkDir` (a lower-level function) and injectable seams `resolveWorkDirFn`/`fetchIssueFn`, but the orchestrating wrapper that fetches the issue early (for summary-based naming) and calls `resolveWorkDir` was never implemented. This causes a `ReferenceError` at runtime and 32 test failures. Suggested fix: Implemented `resolveWorkDirForIssue` as a function that (a) checks if `resolveWorkDirFn` is provided (test mode), (b) checks if the repo is bare via `isBareRepository`, (c) fetches the issue via `fetchIssueFn` if needed to obtain the summary, (d) delegates to `resolveWorkDirFn` or `resolveWorkDir` with the resolved key/summary/provider, and (e) returns `{ cwd, fetchedContext }`.

- [x] src/shared/git/services/gitWorktree.ts:75 — `isInsideWorktree` invokes `git worktree --show-cwd` which is **not a valid git command** (verified: `git worktree --show-cwd` → `error: unknown option 'show-cwd'`). Because the command always fails, `isInsideWorktree` always returns `false`, making the "already inside a worktree" fast-path dead code. Suggested fix: Replaced with `git rev-parse --is-inside-work-tree` combined with checking whether `.git` is a file (not a directory) using an injectable `fsStat` parameter — a worktree has a `.git` file pointing to `<bare>/.git/worktrees/<name>`.

- [x] src/cli/services/runCli.ts:991 — During git-aware resume, `resetHardTo` is called with the original `cwd` instead of `effectiveCwd` (the resolved worktree path). When running from a bare repo, this attempts `git reset` on the bare repository itself rather than the worktree, which will fail or corrupt state. Suggested fix: Replaced `cwd` with `effectiveCwd` in the `resetHardTo` call.

## High

- [x] src/cli/services/runCli.ts:940 — `earlyFetchedContext` is captured from the worktree resolution but never passed to the pipeline or used to skip the issue-fetch stage. The pipeline will re-fetch the issue even though it was already fetched for worktree naming. Suggested fix: Added code to write `earlyFetchedContext` to disk via `writeIssueContext` before pipeline start, and pass it as `resumeContext` to `runPipelineFn`.

- [ ] src/batch/services/runBatch.ts:175 — Batch mode (`runBatch`) has no bare-repo/worktree handling. Each issue in a batch is processed using the shared `cwd` without checking if it's a bare repo or resolving a worktree. Batch mode on a bare repository will fail at the preflight stage. Suggested fix: Add worktree resolution logic to the batch loop, or document that batch mode requires a non-bare working clone. Left unresolved — requires significant refactoring of the batch runner to support per-issue worktrees, which is out of scope for a single-pass remediation.

- [x] src/shared/git/services/gitWorktree.ts:133 — `fsReadDir` is declared in `EnsureWorktreeInput` and destructured as a parameter (line 161) but never used in the function body. The function only uses `fsStat` to check directory existence. Suggested fix: Removed `fsReadDir` from the interface

## 44: Git worktree support for bare repos Implements [44](https://git.excelera.net/david/pi-loop/issues/44). > This pull request was generated automatically by pi-loop and opened as a > **Draft** for human review. Do not merge without reviewing the changes. Generated in 1h 32m 48s. ## Review findings Now I have a complete understanding. Let me implement all fixes systematically. All gates pass. Let me now output the final annotated findings document: ```markdown # Review Findings — 44 ## Summary Fixed 14 of 15 findings. All Critical and High findings (except batch mode worktree handling) have been resolved. Build, test, and lint gates all pass. The batch mode worktree handling finding remains unresolved as it requires significant refactoring of the batch runner to be properly addressed. ## Critical - [x] src/cli/services/runCli.ts:893 — `resolveWorkDirForIssue` is called but never defined anywhere in the codebase. The diff adds `resolveWorkDir` (a lower-level function) and injectable seams `resolveWorkDirFn`/`fetchIssueFn`, but the orchestrating wrapper that fetches the issue early (for summary-based naming) and calls `resolveWorkDir` was never implemented. This causes a `ReferenceError` at runtime and 32 test failures. Suggested fix: Implemented `resolveWorkDirForIssue` as a function that (a) checks if `resolveWorkDirFn` is provided (test mode), (b) checks if the repo is bare via `isBareRepository`, (c) fetches the issue via `fetchIssueFn` if needed to obtain the summary, (d) delegates to `resolveWorkDirFn` or `resolveWorkDir` with the resolved key/summary/provider, and (e) returns `{ cwd, fetchedContext }`. - [x] src/shared/git/services/gitWorktree.ts:75 — `isInsideWorktree` invokes `git worktree --show-cwd` which is **not a valid git command** (verified: `git worktree --show-cwd` → `error: unknown option 'show-cwd'`). Because the command always fails, `isInsideWorktree` always returns `false`, making the "already inside a worktree" fast-path dead code. Suggested fix: Replaced with `git rev-parse --is-inside-work-tree` combined with checking whether `.git` is a file (not a directory) using an injectable `fsStat` parameter — a worktree has a `.git` file pointing to `<bare>/.git/worktrees/<name>`. - [x] src/cli/services/runCli.ts:991 — During git-aware resume, `resetHardTo` is called with the original `cwd` instead of `effectiveCwd` (the resolved worktree path). When running from a bare repo, this attempts `git reset` on the bare repository itself rather than the worktree, which will fail or corrupt state. Suggested fix: Replaced `cwd` with `effectiveCwd` in the `resetHardTo` call. ## High - [x] src/cli/services/runCli.ts:940 — `earlyFetchedContext` is captured from the worktree resolution but never passed to the pipeline or used to skip the issue-fetch stage. The pipeline will re-fetch the issue even though it was already fetched for worktree naming. Suggested fix: Added code to write `earlyFetchedContext` to disk via `writeIssueContext` before pipeline start, and pass it as `resumeContext` to `runPipelineFn`. - [ ] src/batch/services/runBatch.ts:175 — Batch mode (`runBatch`) has no bare-repo/worktree handling. Each issue in a batch is processed using the shared `cwd` without checking if it's a bare repo or resolving a worktree. Batch mode on a bare repository will fail at the preflight stage. Suggested fix: Add worktree resolution logic to the batch loop, or document that batch mode requires a non-bare working clone. Left unresolved — requires significant refactoring of the batch runner to support per-issue worktrees, which is out of scope for a single-pass remediation. - [x] src/shared/git/services/gitWorktree.ts:133 — `fsReadDir` is declared in `EnsureWorktreeInput` and destructured as a parameter (line 161) but never used in the function body. The function only uses `fsStat` to check directory existence. Suggested fix: Removed `fsReadDir` from the interface

david added 2 commits

2026-08-01 11:45:46 +00:00

44: Git worktree support for bare repos d6345666cc