Repository navigation
Allow creating PRs without forking the repository #1486
Description
Activity
Thank you for reporting! You should absolutely be able to create PRs within the same private repository, and gh should only ever auto-fork if you do not have write permissions for the repository. The fact that you're blocked sounds like a bug.
Can you check the result of this query and share it with us? (Replace "OWNER" and "REPO" with your own values.) It should contain no identifiable information
gh api graphql -f owner=OWNER -f repo=REPO -f query=' query($owner:String!, $repo:String!) { repository(owner: $owner, name: $repo) { viewerPermission parent { viewerPermission } } } '
Thanks for sharing your workaround!
Thank you for reporting! You should absolutely be able to create PRs within the same private repository, and gh should only ever auto-fork if you do not have write permissions for the repository. The fact that you're blocked sounds like a bug.
I do have write permissions to the repository, as an organization member. I however cannot fork the private repository, whichI misread your observation :(ghattempts to do because it only checks for my write permission.Can you check the result of this query and share it with us? (Replace "OWNER" and "REPO" with your own values.) It should contain no identifiable information
gh api graphql -f owner=OWNER -f repo=REPO -f query=' query($owner:String!, $repo:String!) { repository(owner: $owner, name: $repo) { viewerPermission parent { viewerPermission } } } '
{ "data": { "repository": { "viewerPermission": "WRITE", "parent": null } } }Thanks for sharing your workaround!
Sure thing :)
If it helps, I also can reproduce this behaviour on a public repository in an org, where I am an organization owner. I didn't report it as a bug earlier since I preferred the forking and it never occurred to me that the write permissions were supposed to be considered.
There is also the case of Reverse Pull Requests. For example, I just did one to update danshearer/cli with all changes from cli/cli. This is another example where forking must not happen.
I did not do this Reverse Pull with gh, because I couldn't quickly see how to do it and I was in a hurry. I need to do some more testing, but in any case I want to remind you of this common use case.
Reacted by Harsh Shandilya@msfjarvis Thanks for the GraphQL response! It looks like you indeed have write access to the target repo. I'm not sure why it would still try to fork the private repo and fail, since it should have defaulted to pushing the branch to that same repo.
BTW, you can debug full verbose mode with
DEBUG=api pr create .... Try to inspect server responses to see if anything stands out.It looks like we might be potentially silencing some errors here
Lines 98 to 101 in b4ffced
If you are comfortable with building
ghlocally, you may try to change it so the error received is reported:r, err := repoContext.HeadRepo() if err != nil { return err } headRepo = r
Then
makeand rerunpr createwith the dev executable that was created inbin/ghof yourcli/clicheckout.If it helps, I also can reproduce this behaviour on a public repository in an org, where I am an organization owner.
Since you have a personal fork of that repository,
gh pr createwill always default to pushing the branch in your fork (if it's not already pushed to a remote). We have already received feedback that this default isn't great and we'll address this in an upcoming release.It seems the behavior is flaky, and now I can't reproduce this issue under the exact same circumstances 🤷
I'm also getting this behaviour:
{ "data": { "repository": { "viewerPermission": "ADMIN", "parent": null } } }I'm going to try building it locally now.
Reacted by Mislav Marohnić@msfjarvis It might have been caused by a network error that caused a failed API request that was then silenced by our improper error handling. It's still a bug and we're going to look into it!
@tomhamiltonstubber Thank you! That would be really helpful 🙇
Reacted by Harsh ShandilyaI came across this error today. I ran
➜ gh pr create --fill ? Where should we push the 'fix-opm-upstream' branch? Create a fork of OrgName/tools cannot fork private repository OrgName/toolsUsing version
gh version 1.9.2 (2021-04-20) https://github.com/cli/cli/releases/tag/v1.9.2and
GitHub Enterprise Server 2.21.19.I tried the exact command a few seconds later and it worked, and successfully create the fork.
Describe the feature or problem you’d like to solve
At my job we rely on private GitHub repositories to house our code and each change goes in through a pull request. Unfortunately, when I run
gh pr create, the CLI will by default always attempt to fork the repository, push to it, and then create a pull request. This particular operation fails withcannot fork private repository, which seems to be expected behavior.Proposed solution
Add a flag to
gh pr create, maybe called--no-fork(?) that would instead push to the current 'origin' remote and create a PR off it.Additional context
So far I've been working around this with an alias that runs
git push origin --set-upstream $(git rev-parse --abbrev-ref HEAD)beforegh pr createwhich seems to 'work' but if there's a possiblity to teachghto not fork it'd be really awesome :)