Skip to content

fix(git): resolve PR badges for untracked prNNNN checkouts by number - #376

Open
omegent-app[bot] wants to merge 1 commit into
fork/devfrom
fix/pr-badge-numeric-branch-fallback
Open

fix(git): resolve PR badges for untracked prNNNN checkouts by number#376
omegent-app[bot] wants to merge 1 commit into
fork/devfrom
fix/pr-badge-numeric-branch-fallback

Conversation

@omegent-app

@omegent-app omegent-app Bot commented Aug 7, 2026

Copy link
Copy Markdown

Closes the last gap in the PR-badge chain: threads whose agents check out a PR with
git fetch origin <head-branch>:prNNNN — a renamed local branch, no upstream tracking.

The problem

The badge lookup finds a thread's PR by head selector: the local branch name, or the head branch
its tracking points to. A pr2182-style checkout has neither — the local name matches no PR's head,
and there is no tracking to derive the real one from. The thread reviewing PR pingdotgg#2182 was the live
case: gh pr list --head pr2182 correctly returns nothing, so the row showed no badge for the very
PR it existed to review. It only lit up after hand-setting branch.pr2182.merge on the worktree.

The fix

In findLatestPrForHeadContext, when the selector search finds nothing and the branch has no
tracking-derived head (headBranch === localBranch) and the name matches ^pr[-_]?\d+$, resolve
the PR by that number via the provider's existing getChangeRequest (gh pr view N /
glab mr show N — provider-neutral). A failed by-number lookup degrades to "no PR", exactly as
before.

The tracking gate matters: a tracked branch that happens to be named pr123 keeps the precise
selector path, so the number can never override a real head selector — covered by the negative test.

Tests

  • status resolves the PR by number for an untracked prNNNN checkout — fails on the pre-fix
    implementation (verified by stashing the fix), passes after; also asserts the pr view 2182 call
    actually happened.
  • status does not resolve by number once a prNNNN branch gains tracking — asserts pr view is
    never called and the row stays badge-less when the tracked head genuinely has no PR.
  • Full GitManager.test.ts: 84 pass. Typecheck clean.

Retroactive by design: existing worktrees need no touch-up — the fallback keys off state the server
reads on every sweep.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

The review-a-PR habit fetches a PR head into a renamed local branch —
`git fetch origin <head-branch>:pr2182` — leaving no upstream tracking. Every
head selector the PR lookup can derive then names a branch that no PR has for
its head, so the thread stays badge-less for the PR it exists to review.

When the selector search finds nothing, the branch has no tracking-derived
head, and its name matches ^pr[-_]?\d+$, resolve the PR by that number via the
provider's getChangeRequest. Gated on headBranch === localBranch so a tracked
branch that merely resembles the pattern keeps the precise selector path; a
lookup failure falls back to "no PR" as before.

Verified against the live case: the "Adversarial Review of PR 2182" thread's
worktree, whose badge only appeared after hand-setting branch tracking — this
makes that repair unnecessary for every past and future such checkout.

Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants