You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
gh pr view and gh pr status still not detecting ongoing PR branch #7590
4 │ Current branch
5 │ There is no pull request associated with [codestartmain]
6 │
7 │ Created by you
8 │ #34108 add default main method for IDE launches [maxandersen:codestartmain]
9 │ - Checks pending - Review required
notice how it says no pull request despite it reporting the same branch (since maxandersen is my branch) being in PR 34108
@maxandersen If you run gh repo set-default --view are you seeing the repo where the PR was created? If not you may just need to change the default repo using gh repo set-default. gh pr view only searches the current default repo for pull requests associated with a branch, not across all known git remotes.
and gh pr status still reports no pr despite it lists it:
Relevant pull requests in quarkusio/quarkus
Current branch
There is no pull request associated with [codestartmain]
Created by you
#34108 add default main method for IDE launches [maxandersen:codestartmain]
× 4/46 checks failing + Changes requested
@maxandersen Thanks for responding. I am still unsure as to why this is happening. Could you rerun the command but this time set the GH_DEBUG=api environment variable? This will output more logs for us to use for debugging. Please sanitize the logs of any personal information before posting them here.
@williammartin
oops, forgot to make fork track upstream/trunk.
gh version 2.71.2-14-gf6dd6997 (2025-04-30)
https://github.com/cli/cli/releases/latest
that being said, issue doesn't happen in trunk, turns out the fedora 41 shipped with outdated github CLI. must've been solved in recent commits.
Name : gh
Epoch : 0
Version : 2.65.0
Release : 1.fc41
Architecture : x86_64
Installed size : 42.6 MiB
Source : gh-2.65.0-1.fc41.src.rpm
From repository : <unknown>
Summary : GitHub's official command line tool
URL : https://github.com/cli/cli
License : Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND ISC AND MIT AND MPL-2.0 AND Unlicense
Description : A command-line interface to GitHub for use in your terminal or your scripts.
:
: gh is a tool designed to enhance your workflow when working with GitHub. It
: provides a seamless way to interact with GitHub repositories and perform various
: actions right from the command line, eliminating the need to switch between your
: terminal and the GitHub website.
Vendor : Fedora Project
EDIT: This bug happened because GitHub repository URL redirects are case-insensitive, while gh pr status is case-sensitive. After fixing the case in the remote definition within .git/config, it now works correctly. I don't exactly remember why the lowercase name was inserted in the first place, tho.
@BagToad hit the same issue today again (tested on trunk):
📦[scarf@fedora Cataclysm]> gh --version
gh version 2.72.0-77-g17af24e1 (2025-05-14)
https://github.com/cli/cli/releases/latest
📦[scarf@fedora Cataclysm]> gh pr-merge
⣟PR 6530: feat: allow choosing color of uilist entry in Lua
Base: main
Head: fix-lua-uilist-entry-color
isNotClosedOrMergedWhenHeadIsDefault: true
headMatches: NappingOcean:fix-lua-uilist-entry-color == nappingocean:fix-lua-uilist-entry-color, baseMatches: main == Empty
no pull requests found for branch "nappingocean:fix-lua-uilist-entry-color"
Details
diff --git a/Makefile b/Makefile
index 32a06df2..48945d8a 100644
--- a/Makefile+++ b/Makefile@@ -74,7 +74,7 @@ endif
## Install/uninstall tasks are here for use on *nix platform. On Windows, there is no equivalent.
DESTDIR :=
-prefix := /usr/local+prefix ?= /usr/local
bindir := ${prefix}/bin
datadir := ${prefix}/share
mandir := ${datadir}/man
diff --git a/pkg/cmd/pr/shared/find_refs_resolution.go b/pkg/cmd/pr/shared/find_refs_resolution.go
index e4e51bab..3f2376af 100644
--- a/pkg/cmd/pr/shared/find_refs_resolution.go+++ b/pkg/cmd/pr/shared/find_refs_resolution.go@@ -106,6 +106,9 @@ func (r PRFindRefs) UnqualifiedHeadRef() string {
func (r PRFindRefs) Matches(baseBranchName, qualifiedHeadRef string) bool {
headMatches := qualifiedHeadRef == r.QualifiedHeadRef()
baseMatches := r.baseBranchName.IsNone() || baseBranchName == r.baseBranchName.Unwrap()
++ fmt.Printf("headMatches: %s == %s, baseMatches: %s == %s\n", qualifiedHeadRef, r.QualifiedHeadRef(), baseBranchName, r.baseBranchName.UnwrapOr("Empty"))+
return headMatches && baseMatches
}
diff --git a/pkg/cmd/pr/shared/finder.go b/pkg/cmd/pr/shared/finder.go
index b8d23c97..09bafc1d 100644
--- a/pkg/cmd/pr/shared/finder.go+++ b/pkg/cmd/pr/shared/finder.go@@ -406,6 +406,11 @@ func findForRefs(httpClient *http.Client, prRefs PRFindRefs, stateFilters, field
// When the head is the default branch, it doesn't really make sense to show merged or closed PRs.
// https://github.com/cli/cli/issues/4263
isNotClosedOrMergedWhenHeadIsDefault := pr.State == "OPEN" || resp.Repository.DefaultBranchRef.Name != prRefs.QualifiedHeadRef()
++ fmt.Printf("PR %d: %s\n", pr.Number, pr.Title)+ fmt.Printf(" Base: %s\n", pr.BaseRefName)+ fmt.Printf(" Head: %s\n", pr.HeadRefName)+ fmt.Printf(" isNotClosedOrMergedWhenHeadIsDefault: %t\n", isNotClosedOrMergedWhenHeadIsDefault)
if prRefs.Matches(pr.BaseRefName, pr.HeadLabel()) && isNotClosedOrMergedWhenHeadIsDefault {
return &pr, nil
}
apparently gh pr checkout lowercases remote name and this causes check in
This is a confirmed bug (already labeled) in how gh pr status detects PRs opened from fork branches. I'm suggesting priority-3 because a workaround exists (specifying the PR number directly, e.g. gh pr view 34108) and the issue affects fork-based PR workflows rather than all users. Note that issue #12203 (open, filed in 2025) appears to be a duplicate of this one - it describes the identical symptom after gh pr checkout from a fork, and references the related closed issue #5914.
Activity
samcoe commentedon Jun 19, 2023
@maxandersen If you run
gh repo set-default --vieware you seeing the repo where the PR was created? If not you may just need to change the default repo usinggh repo set-default.gh pr viewonly searches the current default repo for pull requests associated with a branch, not across all known git remotes.samcoe commentedon Sep 1, 2023
Closing due to lack of response from author.
maxandersen commentedon Sep 1, 2023
sorry - I missed the comment while I was on pto.
it says:
which is the expected default.
and
gh pr statusstill reports no pr despite it lists it:samcoe commentedon Sep 6, 2023
@maxandersen Thanks for responding. I am still unsure as to why this is happening. Could you rerun the command but this time set the
GH_DEBUG=apienvironment variable? This will output more logs for us to use for debugging. Please sanitize the logs of any personal information before posting them here.williammartin commentedon Jan 16, 2024
Closing this due to inactivity but feel free to reopen if it's still an issue and we can move it forward.
maxandersen commentedon Jan 17, 2024
I just got back to this today - same issue with same pr.
Here is gist with debug output https://gist.github.com/maxandersen/76374e5672ff4fdd787e5a915563ba6a
so yes, still happens.
29 remaining items
brettchalupa commentedon Feb 13, 2025
@williammartin That did it, thanks! It's working well now. I also set this:
to keep the workflow pretty similar. I really appreciate the debugging help here.
williammartin commentedon Feb 13, 2025
No problem, I appreciate your quick responses.
auth tests: Set upstream branch earlier
auth tests: Set upstream branch earlier
scarf005 commentedon Apr 30, 2025
hi, I'm stumbling into same issue frequently when attempting to merge PRs after I
gh pr checkout, this time with cataclysmbn/Cataclysm-BN#6465.Debug logs
in
.git/config:remotes
GH_DEBUG=api gh pr list
(irrelevant log truncated)
GH_DEBUG=api gh pr view -w
williammartin commentedon Apr 30, 2025
@scarf005 happy to help you but before diving in I'd like to clear up your
ghversion. You said:Did you build this yourself? The date is today but 2.31.0 is nearly 2 years old.
scarf005 commentedon Apr 30, 2025
@williammartin
oops, forgot to make fork track upstream/trunk.
that being said, issue doesn't happen in trunk, turns out the fedora 41 shipped with outdated github CLI. must've been solved in recent commits.
BagToad commentedon Apr 30, 2025
👋 @scarf005 - yes, we made a lot of changes to PR resolution in recent versions :)
@williammartin I wonder if we can close this issue?
scarf005 commentedon May 13, 2025
EDIT: This bug happened because GitHub repository URL redirects are case-insensitive, while
gh pr statusis case-sensitive. After fixing the case in the remote definition within.git/config, it now works correctly. I don't exactly remember why the lowercase name was inserted in the first place, tho.@BagToad hit the same issue today again (tested on trunk):
Details
apparently
gh pr checkoutlowercases remote name and this causes check incli/pkg/cmd/pr/shared/find_refs_resolution.go
Line 107 in 17af24e
to fail.
jsoref commentedon Oct 20, 2025
There might be a case thing, but what I've seen (I'm using a debugger)
cli/pkg/cmd/pr/shared/finder.go
Line 441 in e627f01
calls:
cli/pkg/cmd/pr/shared/find_refs_resolution.go
Line 107 in e627f01
qualifiedHeadRef = "jsoref:give-mnt-to-container-as-tmp"
cli/pkg/cmd/pr/shared/find_refs_resolution.go
Lines 92 to 97 in e627f01
r.qualifiedHeadRef = "give-mnt-to-container-as-tmp"
So, headMatches = false
I have code that works for this.
fix: use merge ref for PR discovery when push.default=simple and @{pu…
cli-triage commentedon Jul 9, 2026
This is a confirmed
bug(already labeled) in howgh pr statusdetects PRs opened from fork branches. I'm suggestingpriority-3because a workaround exists (specifying the PR number directly, e.g.gh pr view 34108) and the issue affects fork-based PR workflows rather than all users. Note that issue #12203 (open, filed in 2025) appears to be a duplicate of this one - it describes the identical symptom aftergh pr checkoutfrom a fork, and references the related closed issue #5914.BagToad commentedon Jul 9, 2026
As a matter of housekeeping, I'm going to close this out in favour of #12203 which seems to have a bit more recent investigation in it.
gh pr statusshows 'no pull request associated' on a branch pulled viagh pr checkoutfrom a fork #12203