Repository navigation
Choose a specific organization-owned fork as the pull request head #14512
Description
Describe the feature or problem you’d like to solve
An organization can own more than one fork that could supply a pull request branch. An organization and branch alone are therefore not always enough to identify the contributor’s intended head repository.
As a contributor working in an organization with multiple forks, I want to identify the exact head repository, so that the pull request is created from the fork I intended.
Proposed solution
Allow gh pr create --head ORGANIZATION/REPOSITORY:BRANCH to identify the exact organization-owned head repository.
Feature: Choose a specific organization-owned fork as the pull request head
Scenario: The selected fork belongs to another organization
Given the base repository is "org/upstream"
And "other-org/upstream-fork" is a fork of the base repository
When the contributor runs `gh pr create --head other-org/upstream-fork:feature-branch`
Then a pull request is created from "other-org/upstream-fork:feature-branch"
And the pull request targets "org/upstream"
Scenario: The selected fork belongs to the same organization as the base repository
Given the base repository is "org/upstream"
And "org/upstream-fork" is a fork of the base repository
When the contributor runs `gh pr create --head org/upstream-fork:feature-branch`
Then a pull request is created from "org/upstream-fork:feature-branch"
And the pull request targets "org/upstream"
Scenario: The organization owns multiple candidate forks
Given the base repository is "org/upstream"
And "org/upstream-fork" is a fork of the base repository
And "org/experimental-upstream-fork" is a fork of the base repository
When the contributor runs `gh pr create --head org/upstream-fork:feature-branch`
Then a pull request is created from "org/upstream-fork:feature-branch"
And the pull request targets "org/upstream"
Scenario: Repository-qualified head is combined with web mode
When the contributor runs `gh pr create --head other-org/upstream-fork:feature-branch --web`
Then the command fails before opening a browser
And the error explains that a repository-qualified `--head` cannot be used with `--web`
And the error tells the contributor to omit `--web` or select the fork on GitHubAdditional context
This is a sub-issue of #10093.
This issue introduces the repository-qualified ORGANIZATION/REPOSITORY:BRANCH form. The --web behavior may be refined if GitHub’s web pull-request flow can identify the exact head repository.
Activity
gh pr createto support cross repo pull requests within the same organization #10093cli-triage commentedon Sep 23, 2026
Classification: Enhancement (sub-issue of #10093)
Duplicate Check: No exact duplicates found. This is one of three closely related sibling sub-issues opened alongside it under #10093: #14510 (single unique organization-owned fork via
--head ORGANIZATION:BRANCH) and #14511 (tracked-remote fork resolution). #14512 is distinct from both — it specifically covers the fully-qualified--head ORGANIZATION/REPOSITORY:BRANCHform for disambiguating among multiple candidate forks, so it is not a duplicate, just related scope-splitting of the same parent epic.Investigation: The
--headvalue is parsed byParseQualifiedHeadRef, which splits on:into anownerandbranchName, whereowneris currently expected to be a single user/org login (seeQualifiedHeadRef.ownerat lines 25-27). SupportingORGANIZATION/REPOSITORY:BRANCHwould require extending this owner segment to optionally carry a repository name (e.g. viaghrepo.Interface) and threading that through fork resolution inpkg/cmd/pr/create/create.go(wherequalifiedHeadRefcurrently only carries an owner, not a full repo). This is a reasonable, well-scoped feature request with clear acceptance criteria (Gherkin scenarios included) and no missing information needed to start engineering review.I'm suggesting
enhancementandgh-prlabels for this feature request; no priority label applies since it isn't a bug.github-actions commentedon Sep 24, 2026
Thank you for your issue! We have categorized it as an enhancement (feature or improvement) request, and it has been added to our backlog. In doing so, we are not committing to implementing this feature at this time, but, we will consider it for future releases based on community feedback and our own product roadmap.
Unless you see the help wantedContributions welcome
label, we are not currently looking for external contributions for this feature.
If you come across this issue and would like to see it implemented, please add a thumbs up! This will help us prioritize the feature. Please only comment if you have additional information or viewpoints to contribute.