Repository navigation
Cover the inbound symptom of a restricted fetch refspec in Edge cases - #177
dmccoystephenson wants to merge 2 commits into
Conversation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Self-review rubric (an inline review was performed in a headless dispatch, with no independent reviewer):
Judgment calls flagged for a reviewer:
Because of the UNVERIFIED behavioral item, this PR is not merged autonomously and is left for a maintainer. This review was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener). drafted by Claude on behalf of Daniel Stephenson |
There was a problem hiding this comment.
🟡 Changes recommended
The unconditional git log check fails when the local branch is absent, blocking the intended recovery; it must run only for existing branches and succeed with no commits before allowing a forced update.
1 open issue
What changed in this PR
Extends the generated skill’s restricted-fetch-refspec guidance to cover inbound branch checkout failures, alongside the existing PR-creation workaround.
Changes:
- Retitles the Edge cases entry to make both error messages discoverable.
- Adds explicit fetch instructions and checks for stale local branches and unpushed commits.
| File | Description |
|---|---|
create-dev-loop.md |
Expands restricted-refspec troubleshooting in the generated skill template. |
Review effort: Balanced
| **A review comment is a false positive:** reply with evidence, do not apply the change. | ||
| **A `gh` command fails with a transient network/transport error (`http2: client conn could not be established`, `unexpected EOF`):** retry once or twice before treating it as blocked — do not treat the first failure as terminal and silently drop a self-review, commit, or comment. | ||
| **`gh pr create` fails with "you must first push the current branch to a remote" despite a successful `git push -u`:** the clone's fetch refspec may be restricted to the default branch only (common in gardener-managed or otherwise restricted dedicated checkouts) — confirm with `git config --get-all remote.origin.fetch`. A restricted refspec means `git fetch` never populates a remote-tracking ref for feature branches, so `gh pr create`'s and `git branch --set-upstream-to`'s auto-detection both fail even though the push and upstream config succeeded. Pass `--head <branch>` explicitly to `gh pr create` to bypass the remote-tracking-ref lookup rather than retrying the push. | ||
| **Restricted fetch refspec — `gh pr create` fails with "you must first push the current branch to a remote" despite a successful `git push -u`, or `git checkout <branch>` fails with `error: pathspec '<branch>' did not match any file(s) known to git` for a branch that exists on the remote:** the clone's fetch refspec may be restricted to the default branch only (common in gardener-managed or otherwise restricted dedicated checkouts) — confirm with `git config --get-all remote.origin.fetch`. A restricted refspec means `git fetch` never populates a remote-tracking ref for feature branches, and it has two symptoms. *Outbound (a branch this clone just pushed):* `gh pr create`'s and `git branch --set-upstream-to`'s auto-detection both fail even though the push and upstream config succeeded. Pass `--head <branch>` explicitly to `gh pr create` to bypass the remote-tracking-ref lookup rather than retrying the push. *Inbound (an existing remote branch, e.g. a carried-over PR's branch in Phase 1):* `git fetch origin <branch>` succeeds but writes only `FETCH_HEAD`, so the checkout error reads as "the branch does not exist" — it does exist; only the mapping into a local ref is missing. Do not re-fetch the same way or start fresh work. From the default branch, run `git fetch origin +<branch>:<branch>`, which creates the local branch directly, then check it out. The `+` matters because such clones are often reused across runs and can keep a **stale local branch of the same name** — in that case a plain `git checkout <branch>` succeeds silently onto the old commit, so compare `git rev-parse <branch>` against `gh pr view <number> --json headRefOid` before trusting it. The forced update discards local-only commits on that branch, so first run `git fetch origin <branch>` and confirm `git log FETCH_HEAD..<branch>` is empty (no unpushed work). |
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Copilot's finding ("Skip local-commit check when the branch is absent") was confirmed and addressed in 98bfb83.
The behavioral This comment was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener). drafted by Claude on behalf of Daniel Stephenson |

Summary
The restricted-fetch-refspec entry in the generated-skill template's Edge cases section is extended to cover the inbound symptom reported in #130. The entry is retitled so that it can be found from either error message.
gh pr createauto-detection, and the fix is--head <branch>.git fetch origin <branch>writes onlyFETCH_HEAD, sogit checkout <branch>fails witherror: pathspec '<branch>' did not match any file(s) known to gitfor a branch that does exist on the remote.git fetch origin +<branch>:<branch>is prescribed from the default branch.git checkout <branch>can succeed silently onto a stale local copy. Two checks were added:git rev-parse <branch>is compared with the PR'sheadRefOid, andgit log FETCH_HEAD..<branch>must be empty before the forced update, so that unpushed work is not discarded. The+was added to the issue's suggested<branch>:<branch>form for this reason.{{#if REVIEWER}}entry to be read as a lazy continuation of the last list item.Closes #130
gardener interface: Steps 3, 5, and 6 are untouched, so no breaking change is introduced for gardener.
Retrofit: the Edge cases section is copied into every generated skill, so a retrofit pass is likely needed for every existing
<slug>-dev-loopskill that carries the oldgh pr create-only entry.create-dev-loop-dev-loopis one of them.Research grounding
No
RESEARCH.mdfinding applies. This is plain Git refspec behavior, as stated in #130, so no Implementations entry is added.Doc sync check
README.md's "What it does" Step list still matchescreate-dev-loop.md's Steps 1:1 (no Step was changed){{placeholder}}was added. The existing{{DEFAULT_BRANCH}}is not used in the new text.Test plan
python3 scripts/check_docs.py: "Doc consistency check passed."python3 -m unittest discover -s tests: 42 tests were run, OK.+refs/heads/main:refs/remotes/origin/main, git 2.25.1).git fetch origin fix/negated-closing-keywordswrote onlyFETCH_HEAD, and the checkout failed with the quotedpathspecerror.fix/negated-closing-keywordswas present,git checkoutsucceeded without any tracking message.git fetch origin +fix/negated-closing-keywords:fix/negated-closing-keywordswas then run against a local branch reset to855a4b7, and it reported(forced update)toec84115, the remote tip. The scratch branch was deleted afterward./create-dev-looprun was performed, because a GitHub repo is created in Step 6 and files outside the checkout are written in Steps 3 and 5, and neither is authorized in a headless dispatch ([self-audit] The repo's own validation anchor is structurally unrunnable in a headless dispatch, so template changes can never merge autonomously #109). None of the fiveCLAUDE.mdchecklist items was exercised, so this PR is left for a maintainer to merge.Issues not picked this cycle
CLAUDE.mdhalf of Step 4 and CLAUDE.md still place the version comments at the top of the generated skill #173: explicit authorization is required forCLAUDE.mdedits.for-loop rework (per its comment) is needed, which is larger than this one-entry fix.This PR description was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener).
🤖 Generated with Claude Code
drafted by Claude on behalf of Daniel Stephenson