Repository navigation
Create pull requests from a uniquely identifiable organization-owned fork #14510
Description
Describe the feature or problem you’d like to solve
Contributors can identify a user-owned fork with --head OWNER:BRANCH, but the same workflow does not support forks owned by organizations. This blocks contributors whose work lives in an organization-owned fork, including forks owned by the same organization as the upstream repository.
As a contributor working from an organization-owned fork, I want to identify the fork by its organization and branch when there is only one possible match, so that I can create a pull request without needing to provide the complete repository name.
Proposed solution
Allow gh pr create --head ORGANIZATION:BRANCH to select an organization-owned head repository when exactly one matching fork can be identified.
Feature: Create a pull request from a uniquely identifiable organization-owned fork
Scenario: The fork belongs to another organization
Given the base repository is "org/upstream"
And "other-org" owns exactly one matching fork
And the matching fork is "other-org/upstream-fork"
When the contributor runs `gh pr create --head other-org:feature-branch`
Then a pull request is created from "other-org/upstream-fork:feature-branch"
And the pull request targets "org/upstream"
Scenario: The fork belongs to the same organization as the base repository
Given the base repository is "org/upstream"
And "org" owns exactly one matching fork
And the matching fork is "org/upstream-fork"
When the contributor runs `gh pr create --head org:feature-branch`
Then a pull request is created from "org/upstream-fork:feature-branch"
And the pull request targets "org/upstream"Additional context
This is a sub-issue of #10093.
This issue covers ORGANIZATION:BRANCH when exactly one matching organization-owned fork can be identified. Selecting among multiple possible forks is covered separately.
Activity
gh pr createto support cross repo pull requests within the same organization #10093cli-triage commentedon Sep 23, 2026
Classification: Enhancement
Information Assessment: This is a well-specified feature request that clearly documents the current behavior and the desired improvement, with Gherkin scenarios covering the exact matching case. It is filed as a sub-issue of #10093, and no duplicates of its specific scope (
ORGANIZATION:BRANCHresolving to exactly one fork) were found among the related sub-issues (#14511, #14512) or other search results.Root cause hypothesis: In
createContextinpkg/cmd/pr/create/create.go, when--headis supplied, the code parses it viashared.ParseQualifiedHeadRefand relies entirely on the GitHub API to resolve<owner>:<branch>into a fork, with the comment noting "organizations don't work at all with this ref format" (create.go lines 833-838, commit a3d31e2764f110dd03c46136177360bc78dc3f63). This matches the reporter's description: today the flow only works when<owner>maps to the user's own fork namespace, since GitHub only auto-resolves a single fork per user, not per organization. Implementing this would requireghto itself look up organization-owned forks (e.g. via the API) when<owner>is an org, rather than relying on the GitHub API's implicit single-fork resolution.I'm suggesting
enhancementand thegh-prcommand label, since this is a clear, actionable feature request scoped togh pr create's--headflag with no duplicates found.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.
ekam-walia commentedon Sep 25, 2026
HI @williammartin, I am happy to take upon this issue, Can you please assign this to me