Repository navigation
Option to push branch into a specific remote #480
Description
Activity
Thanks for writing in!
currently when you open a pr from a branch, it's pushed into the repo it's originated from.
We only push to the origin repo if you have write access to it in the first place. Is there a use-case where you have write access to the origin repo, but you still don't want to push there?
Also, does this push fail for you right now?
this would fit lots of the workflows in lots of opensource projects when you don't have write-access to the main repo.
When you don't have write access to the main repo, we fork it and push to your fork instead. This all happens by default. If you do not experience that this works, can you tell us more about your setup and paste some error messages?
- addedmore-info-neededMore info needed from user/contributorMore info needed from user/contributor
on Feb 17, 2020 I have a fork already, and I have write access to both.
$ git remote -v origin [email protected]:fruch/scylla-cluster-tests.git (fetch) origin [email protected]:fruch/scylla-cluster-tests.git (push) upstream [email protected]:scylladb/scylla-cluster-tests.git (fetch) upstream [email protected]:scylladb/scylla-cluster-tests.git (push)origin is my fork
when I've used
gh pr createfrom a branch created from upstream/master, the branch was pushed to upstream and not into origin as I would like to.Some more info, pushing into the upstream in my case, trigger more CI build which. the work flow of the whole team is to work on your own fork.
I've run into it, since after creating the PR, I've pushed updated to my own fork, and not seeing them in the PR.
maybe my workflow is a bit weird or backwards, but it would be nice to have a bit more control when needed.
maybe my workflow is a bit weird or backwards, but it would be nice to have a bit more control when needed.
Your workflow doesn't seem weird at all; thanks for clarifying.
I will close this as duplicate of #350 where people have been requesting the option to indicate their preference that they want to always push to a fork instead of to upstream, even if they have write access.
@casperdcl I understand that this is not an exact duplicate, but in the referenced thread we're discussing a better default for where the branch is pushed, plus we're planning to respect if the branch is already pushed to a specific remote. The combination of those two improvements should make a vast improvement in experience for our users:
gh pr createby default will always push to a fork if one exists - this will be a better default since the considerable majority of users have asked for this. A better default (ideally) means that fewer people will need an option to change it.git push <remote> HEAD && gh pr createwill allow one to choose where the branch is pushed, alleviating the need for--remoteflag.
At this moment we're trying to avoid adding too many configuration flags because that could over time prove to be difficult to maintain.
on the other hand, quietly setting defaults without exposing config options is also dangerous. I don't personally mind, but others might. Happy if (2) works:
git checkout upstream/master git checkout -b <branch> git push -u <fork> <branch> gh pr create
will auto-create a PR
fork:branch->upstream:masterReacted by Mislav MarohnićI'm run into this issue today, and surprisingly someone already suggested here what I need in 2020... thanks @fruch you know exactly what I need...
just to add to who here, this option does exist now
gh create ... --head origin:branch_name- added a commit that references this issue
on Jul 21, 2025
Describe the feature or problem you’d like to solve
I'm working with forks on lots of my projects
currently when you open a pr from a branch, it's pushed into the repo it's originated from.
Proposed solution
I would be helpful if we could define which remote to push to, maybe even in some defaults inside .git
Additional context
this would fit lots of the workflows in lots of opensource projects when you don't have write-access to the main repo.