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
Describe the feature or problem you’d like to solve
I think the current search functionality of gh pr list has surprising behavior in that the --head foo argument or head:foo search atom will return any PR whose head branch starts with "foo". This appears to match the behavior of the web UI (https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests#search-by-branch-name). While this arguably makes sense for an interactive web interface, I think this is surprising behavior for a command line interface and scripting tool. This is especially bad because there doesn't seem to be any way to search for an exact match
Proposed solution
Options:
Make the search atom and flag for the head branch perform an exact match. To perform a prefix match, the syntax could be extended with standard * wildcards or full regex.
Add a method to specify an exact search. Maybe quoting the branch name?
Of these, I prefer number 1. I think this is what the behavior should have been in the first place and is the expected behavior for this sort of tool. But I understand this would be a breaking change, so some alternative syntax would be another option. I think that's going to be a lot more awkward though.
Additional context
My use case is searching for merged PRs that match my local branches so that I can clean them up. Obviously an exact match is important here.
Thanks for reading out about this concern, @GMNGeoffrey! 🙇
Questions
Can you show me a public repository where you've encountered this problem with gh pr list --head ... including the PRs and related branches?
Unable to reproduce reported behavior
Sadly, I was not able to reproduce the problem you describe as I crafted 2 separate pull requests in the same repository with the same branch naming base (cli-10816) with one having a suffix.
As you can see in the shell snippet below, gh pr list --head only receives exact matches back. 🤔
$ git branch | cat
cli-10816
* cli-10816-2
main
$ gh version
gh version 2.70.0 (2025-04-11)
https://github.com/cli/cli/releases/tag/v2.70.0
$ gh pr list --head cli-10816
Showing 1 of 1 pull request in tinyfists/gh-pr-test that matches your search
ID TITLE BRANCH CREATED AT
#8 Adding file from cli-10816 branch cli-10816 about 2 minutes ago
$ gh pr list --head cli-10816-2
Showing 1 of 1 pull request in tinyfists/gh-pr-test that matches your search
ID TITLE BRANCH CREATED AT
#9 Adding files from cli-10816-2 branch cli-10816-2 less than a minute ago
Additionally, here are examples from the cli/cli repository as we have several PRs where branches have similar bases that this should show up but doesn't:
cli/cli $ gh pr list --state all --head "dependabot/go_modules/google.golang.org/protobuf-1.36"
no pull requests match your search in cli/cli
cli/cli $ gh pr list --state all --head "dependabot/go_modules/google.golang.org/protobuf-1.36.3"
Showing 1 of 1 pull request in cli/cli that matches your search
ID TITLE BRANCH CREATED AT
#10250 Bump google.golang.org/protobuf from 1.36.2 to 1.36.3 dependabot/go_modules/google.golang.org/protobuf-1.36.3 about 3 months ago
cli/cli $ gh pr list --state all --head "dependabot/go_modules/google.golang.org/protobuf-1.36.4"
Showing 1 of 1 pull request in cli/cli that matches your search
ID TITLE BRANCH CREATED AT
#10306 Bump google.golang.org/protobuf from 1.36.3 to 1.36.4 dependabot/go_modules/google.golang.org/protobuf-1.36.4 about 2 months ago
cli/cli $ gh pr list --state all --head "dependabot/go_modules/google.golang.org/protobuf-1.36.5"
Showing 1 of 1 pull request in cli/cli that matches your search
ID TITLE BRANCH CREATED AT
#10379 Bump google.golang.org/protobuf from 1.36.4 to 1.36.5 dependabot/go_modules/google.golang.org/protobuf-1.36.5 about 2 months ago
cli/cli $ gh pr list --state all --head "dependabot/go_modules/google.golang.org/protobuf-1.36.6"
Showing 1 of 1 pull request in cli/cli that matches your search
ID TITLE BRANCH CREATED AT
#10659 Bump google.golang.org/protobuf from 1.36.5 to 1.36.6 dependabot/go_modules/google.golang.org/protobuf-1.36.6 about 24 days ago
Thanks for the quick response. I think you're right that this actually doesn't apply to the --head flag: only the head: search atom. I thought I checked that, but apparently not correctly...
$ gh pr list -R cli/cli --state all --head "dependabot/go_modules/google.golang.org/protobuf-1.36"
no pull requests match your search in cli/cli
$ gh pr list -R cli/cli --state all --search "head:dependabot/go_modules/google.golang.org/protobuf-1.36"
Showing 4 of 4 pull requests in cli/cli that match your search
ID TITLE BRANCH CREATED AT
#10659 Bump google.golang.org/protobuf from 1.36.5 to 1.36.6 dependabot/go_modules/google.golang.org/protobuf-1.36.6 about 24 days ago#10379 Bump google.golang.org/protobuf from 1.36.4 to 1.36.5 dependabot/go_modules/google.golang.org/protobuf-1.36.5 about 2 months ago#10306 Bump google.golang.org/protobuf from 1.36.3 to 1.36.4 dependabot/go_modules/google.golang.org/protobuf-1.36.4 about 2 months ago#10250 Bump google.golang.org/protobuf from 1.36.2 to 1.36.3 dependabot/go_modules/google.golang.org/protobuf-1.36.3 about 3 months ago
I think a fuzzy match is actually more justifiable in the context of a search string. The issue is that the generic search query is the only way to search for multiple head branches AFAICT, so there's no way to get PRs for branch 'foo' and branch 'bar', but not 'foobar' other than filtering after the fact.
I think you're right that this actually doesn't apply to the --head flag: only the head: search atom. I thought I checked that, but apparently not correctly...
$ gh pr list -R cli/cli --state all --head "dependabot/go_modules/google.golang.org/protobuf-1.36"
no pull requests match your search in cli/cli
$ gh pr list -R cli/cli --state all --search "head:dependabot/go_modules/google.golang.org/protobuf-1.36"
Showing 4 of 4 pull requests in cli/cli that match your search
ID TITLE BRANCH CREATED AT #10659 Bump google.golang.org/protobuf from 1.36.5 to 1.36.6 dependabot/go_modules/google.golang.org/protobuf-1.36.6 about 24 days ago #10379 Bump google.golang.org/protobuf from 1.36.4 to 1.36.5 dependabot/go_modules/google.golang.org/protobuf-1.36.5 about 2 months ago #10306 Bump google.golang.org/protobuf from 1.36.3 to 1.36.4 dependabot/go_modules/google.golang.org/protobuf-1.36.4 about 2 months ago #10250 Bump google.golang.org/protobuf from 1.36.2 to 1.36.3 dependabot/go_modules/google.golang.org/protobuf-1.36.3 about 3 months ago
I think a fuzzy match is actually more justifiable in the context of a search string. The issue is that the generic search query is the only way to search for multiple head branches AFAICT, so there's no way to get PRs for branch 'foo' and branch 'bar', but not 'foobar' other than filtering after the fact.
Thanks for the follow up and additional context, @GMNGeoffrey! 🙇
Yeah I'm doing client-side filtering with jq now. It's a bit more involved to construct than your example because I'm trying to find a whole list of exact matches, but it works (https://gist.github.com/GMNGeoffrey/38d27939cb751ab066df59927f807f37 if anyone's curious). I still found the implicit fuzzy matching of gh (because of the GitHub API) surprising, but I think it's a reasonable design decision for a "search" endpoint. I guess the thing I would want is either the ability to OR filters like --head in the gh pr list command (without the search flag, which seems to activate a totally different path) or the ability to specify an exact match in the GitHub PR search API. I think this isn't obviously a flaw in the current implementation though, and it seems likely only worth it if you get other people who want the same thing
Activity
andyfeller commentedon Apr 17, 2025
Thanks for reading out about this concern, @GMNGeoffrey! 🙇
Questions
gh pr list --head ...including the PRs and related branches?Unable to reproduce reported behavior
Sadly, I was not able to reproduce the problem you describe as I crafted 2 separate pull requests in the same repository with the same branch naming base (
cli-10816) with one having a suffix.As you can see in the shell snippet below,
gh pr list --headonly receives exact matches back. 🤔Repo: https://github.com/tinyfists/gh-pr-test
Branches:
PRs:
Additionally, here are examples from the
cli/clirepository as we have several PRs where branches have similar bases that this should show up but doesn't:GMNGeoffrey commentedon Apr 17, 2025
Thanks for the quick response. I think you're right that this actually doesn't apply to the
--headflag: only thehead:search atom. I thought I checked that, but apparently not correctly...I think a fuzzy match is actually more justifiable in the context of a search string. The issue is that the generic search query is the only way to search for multiple head branches AFAICT, so there's no way to get PRs for branch 'foo' and branch 'bar', but not 'foobar' other than filtering after the fact.
andyfeller commentedon Apr 21, 2025
Thanks for the follow up and additional context, @GMNGeoffrey! 🙇
I think you're correct:
the
--base/--headflags are used to exact match byRepository.pullRequeststhe
--searchflag relies uponsearchquery wherebase/headsearch qualifiers are fuzzy matched server-sideyou could filter this client-side using the
--jsonand--jqflagsresulting in:
[ { "headRefName": "dependabot/go_modules/google.golang.org/protobuf-1.36.6", "number": 10659, "title": "Bump google.golang.org/protobuf from 1.36.5 to 1.36.6", "url": "https://github.com/cli/cli/pull/10659" }, { "headRefName": "dependabot/go_modules/google.golang.org/protobuf-1.36.3", "number": 10250, "title": "Bump google.golang.org/protobuf from 1.36.2 to 1.36.3", "url": "https://github.com/cli/cli/pull/10250" } ]Questions
How does this context reshape this suggestion? Are you suggesting:
headandbasematching?Debug output from above commands
gh pr list --state all --head "dependabot/go_modules/google.golang.org/protobuf-1.36.3"gh pr list -R cli/cli --state all --search "head:dependabot/go_modules/google.golang.org/protobuf-1.36"[-]PR search by exact branch name[/-][+]PR search by multiple exact branch names[/+]GMNGeoffrey commentedon Apr 21, 2025
Yeah I'm doing client-side filtering with
jqnow. It's a bit more involved to construct than your example because I'm trying to find a whole list of exact matches, but it works (https://gist.github.com/GMNGeoffrey/38d27939cb751ab066df59927f807f37 if anyone's curious). I still found the implicit fuzzy matching ofgh(because of the GitHub API) surprising, but I think it's a reasonable design decision for a "search" endpoint. I guess the thing I would want is either the ability toORfilters like--headin thegh pr listcommand (without the search flag, which seems to activate a totally different path) or the ability to specify an exact match in the GitHub PR search API. I think this isn't obviously a flaw in the current implementation though, and it seems likely only worth it if you get other people who want the same thing