Stop hook: a branch pushed from an add_repo clone always reads as unpushed

[bdelanghe]

Fallout surfaced by #215 (issue #214). The scope fix there was correct; it exposed a pre-existing assumption in the per-repo predicate that is wrong for the clones add_repo produces.

Symptom

At Stop, in a session that used add_repo:

/workspace/verbspec: Branch 'claude/next-jybxja' has 1 unpushed commit(s) and no remote branch.
Please push these changes to the remote repository.

The branch was pushed. Its PR was reviewed and squash-merged. The remote branch still exists.

Mechanism

add_repo instructs git clone --depth 1, which writes a single-branch fetch refspec. Measured in /workspace/verbspec while the message above was firing:

remote.origin.fetch              = +refs/heads/main:refs/remotes/origin/main
branch.<branch>.merge            = refs/heads/<branch>        (push -u DID set tracking)
refs/remotes/                    = origin/HEAD, origin/main   (and nothing else)
git ls-remote --heads origin <branch>  ->  the branch EXISTS on the remote

The hook decides "is this pushed?" with git rev-parse origin/$current_branch — a purely local remote-tracking ref. Under a single-branch refspec that ref is never created, no matter how many successful pushes happen. So the hook falls through to upstream=origin/HEAD, reports "no remote branch", and counts the commit as unpushed.

Why it matters now

Before #215, /workspace checkouts were never examined, so this could not fire. Now every session that adds a repo mid-session and pushes a branch will hit it — permanently, including immediately after a clean push, and forever after the PR merges.

That is the cries-wolf mode this repo already names as worse than no hook: "A hook that cries wolf on every merge is worse than no hook: it teaches you to ignore the one time it is right." The existing infra#112 exclusion does not help — it covers a local branch reset onto the merged default branch, not a branch whose remote-tracking ref was never fetched.

Proposed fix

Narrow, and only on the path that is already failing. Where origin/$branch does not resolve but branch.$name.merge is configured, ask the remote before concluding anything:

git ls-remote --heads origin "$branch"

and compare the returned sha against HEAD / containment. A network call lands only in the single-branch-clone case, not on every Stop.

Worth deciding alongside: whether the discovery in #215 should instead fetch the branch ref for /workspace clones so the local ref exists in the first place. The ls-remote route is cheaper and does not mutate the checkout.

Acceptance

• A branch pushed from a --depth 1 single-branch clone does not report as unpushed.
• Genuinely unpushed work in such a clone still reports.
• A test covers the single-branch-refspec shape specifically, and fails without the fix.

[bdelanghe]

Independent reproduction in a second repo, plus a sub-case the proposed fix does not cover as written.

Reproduction

Hit at Stop today in /workspace/infra, an add_repo clone, after #429 there squash-merged:

/workspace/infra: Branch 'claude/next-uwocl0' has 2 unpushed commit(s) and no remote branch.
Please push these changes to the remote repository.

Same mechanism you measured, confirmed in this checkout:

remote.origin.fetch                = +refs/heads/main:refs/remotes/origin/main
refs/remotes/                      = origin/HEAD, origin/main   (and nothing else)
branch.claude/next-uwocl0.merge    = refs/heads/claude/next-uwocl0   (push -u DID set tracking)

So this is not specific to verbspec — it is the add_repo clone shape, as you diagnosed.

The sub-case the fix misses

Your proposal is to run git ls-remote --heads origin "$branch" on this path and compare the returned sha against HEAD/containment. In your reproduction the branch exists on the remote, so there is a sha to compare.

Here there is not:

$ git ls-remote --heads origin claude/next-uwocl0
(empty)

The branch was genuinely deleted on merge. So ls-remote returns nothing, and a fix that concludes from "no sha returned" that the work is unpushed lands back on the same false positive — for the case that is arguably the most common end state, since delete-on-merge is on.

The work was merged: 663c24d went in as 8b00095, and git diff 663c24d origin/main -- cloudflare/boot/src/payloads.mjs was empty.

This is the harmful one. For an existing remote branch the message is merely noise. Here, following it literally pushes already-merged history back onto a branch the merge deleted — recreating it — which is exactly what the org's own guidance forbids ("a merged PR is finished… never stack new commits on top of the already-merged history"). The remedy the message gives is wrong, not just unnecessary. The correct action was to restart the branch from the merged default, which is what I did.

Why it said "2", not "1"

Worth recording, because it is a third interacting cause and it inflates the number:

$ cat .git/shallow
359d56fe…   8b00095…   e68bca26…
$ git rev-list --count origin/main
1

--depth 1 grafts origin/main, so 8b00095 has no visible ancestors. git rev-list HEAD --not origin/main therefore returns {663c24d, 359d56f} — the local commit plus the shared base, because the graft severs the parent link that would otherwise exclude it. So in a shallow clone the count is not "commits you authored"; it can include the merge base itself.

Suggested addition

When origin/$branch does not resolve and ls-remote returns nothing, do not conclude "unpushed" — test containment against the default branch instead (patch-equivalence via git cherry, or a tree/path diff), and if the work is already contained, say so and point at git checkout -B "$branch" origin/<default> rather than at git push. The two states need different messages because they need opposite actions.

Suggested extra acceptance criterion:

• A branch whose remote counterpart was deleted on merge, whose commits are already contained in the default branch, reports either nothing or a reset instruction — never push. Covered by a test in the shallow single-branch-refspec shape.

Found while doing bounded-systems/.github-private#611; not claiming this issue.

---

Generated by Claude Code