Change default base repository for pull requests on forks

[caroso-de]

I've forked a repository which has been archived by the owner, so there won't be any prs accepted to the original repository.
Therefore I'd like to change the base repository for all PRs made from to my repository but this seems not possible.

Is there a recommended way to deal with this situation other than (re)creating the repository without forking?

Thanks a lot!

[rcoup]

More discussion at https://github.community/t/changing-the-default-pr-target-when-creating-a-pr-from-a-fork/2842/2

[lululime]

This is a dead link. However, when I created a fork within an org, the PRs I made in that fork defaulted to the fork, not to the upstream repo for PRs.

@dawaszl and I are both working on this.

[per1234]

Although it seems that GitHub removed all the community discussions that were previously hosted on the github.community Discourse forum when they switched to using GitHub Discussions, I did find an archived copy of the discussion @rcoup referenced on the Internet Archive Wayback Machine.

It doesn't contain anything of significant value, but I'll share the link anyway in order to save others the time of hunting for the referenced discussion:

https://web.archive.org/web/20200928154342/https://github.community/t/changing-the-default-pr-target-when-creating-a-pr-from-a-fork/2842

[ALNPRA123]

why not to try that ,but i like js system to fix that role rm

[usirg]

GitHub has a default branch setting. The page says:

The default branch is the base branch for pull requests and code commits.

Unless I am missing something, that setting is not respected for PRs on a fork, given that the default branch of the upstream repo seems to be taken as the base branch for the PR.

How about adding a default base repo setting to forks? The two settings could then initially be set as follows:

• default base repo: upstream
• default branch: default branch of upstream repo

When creating a PR, these settings could be used to give the current behavior.

Then users could change the settings to fit their needs.

I'd be happy to learn about any implications I might be missing 😁

[ALNPRA123]

very good sir,good work for this

[jkoutavas]

Has anyone got an update on how to change the base repo?

[ALNPRA123]

no but change repo,i might be lost for a time if i send for my work

[jarupxx]

To change this behaviour you'd have to change the Compare page URL by external add-ons.

https://github.com/<OWNER>/<BASE REPO>/compare/<BRANCH>...<FORK REPO>:<BRANCH>
https://github.com/<YOUR>/<FORK REPO>/compare/<BRANCH>...<FORK REPO>:<BRANCH>

I'm talking a green pull request button.

[slifty]

The current developer experience is really hard to work with -- I've incorrectly opened (and then closed) PRs to upstream several times at this point and I'm going to have to just remove my upstream association which is a real shame. Would love a solution to this for future projects!

[jamesmortensen]

I was wondering if it's possible to mirror the fork and your unassociated repo? Could you still keep in sync with upstream by having an extra layer between your unassociated repo and the fork? I've added multiple upstream entries using git remote add but I am not entirely sure how to do that by default when cloning...

If this works, you could submit pull requests to the unassociated repo, which would default to the unassociated master/main branch. Every now and then, you could theoretically do a git push fork master to sync changes to the fork. Then if you needed to sync the fork, you could then do the reverse and pull upstream changes through the fork.

I've never done this before, but it might be worth exploring.

I have the same problem. I'm maintaining a fork of an upstream repo and we and the upstream team agree that nothing in the fork is intend to merge upstream. But we keep in sync with upstream's new features. I've almost accidentally merged a year's worth of commits into the upstream repo due to the association as a fork.

[ALNPRA123]

git push remote is very harder to get this ,i use base repo for first time,can be use github dekstop to handle that

[tim-hilt]

Same problem here! Just today I closed a PR just clicks before merging it to master on the wrong repository.

[ALNPRA123]

oh my god,but you have a backup for that bro ?

[r-LaForge]

I can attest - this is very annoying.
Would really appreciate a safeguard (changing the default repo / branch) to prevent accidentally spamming upstream.

[ALNPRA123]

branch master is very good answer i very appreciate to github company can handle this

[sebhmg]

same experience here. My solution was finally to create fork form the fork:
upstream <- organization fork <- user fork
This way, pull requests created form the "user fork" are targeting the organization fork, as desired.

[ALNPRA123]

use fork hard but funny respon lol

[nuhasha]

The output of git push -u origin <branchname> that includes the URL that will be used to create the pull request.
After open this URL in browser, and before you click Create Pull Request, first change the base branch to be your forked PR instead of the originally forked PR. then create the pull request.

[slifty]

Yes -- I believe the issue is that last step (having to manually change) is non-ideal and leads to accidental PRs if your default target is going to be the immediate repository rather than upstream. The request is to change the default behavior / value for that dropdown.

[jamesmortensen]

Yeah. Manual steps are error prone and don't scale, and then when you add another collaborator to your fork they have that same dangerous learning curve to overcome.

It is especially dangerous if you're also a maintainer on the upstream repo. I almost accidentally merged in a years worth of commits.

[shakefu]

Why is this not a setting? One of the main use cases for Forking a repository is to take over a project that is out of maintenance - where the previous owner is ignoring all PRs.

Please @github-staff consider just making it a setting so we don't have to click 3 times on every PR to avoid accidentally PR'ing the fork. Thanks.

[MKL-SebastianLoeffler]

PLEASE!!!

[CoenraadS]

This behavior is so frustrating. As a workaround, to detach a repository you can request a ticket here: https://support.github.com/contact?tags=rr-forks&subject=Detach%20Fork&flow=detach_fork

[radekg]

Please provide this setting.

[ferminho]

Same situation here, we want to work mainly in our fork and contribute some PRs upstream, so we don't want to detach. We had some accidental PRs already, and it's embarrassing. Please let us configure the default

[vincerubinetti]

I have a website template that people fork to use, and the github.com UI for pull requests defaulting to the upstream repo instead of the base repo has caused so many people (including me!) to open accidental PRs (against the template itself instead of their own main branch) that I had to create a label specifically for it:

[ALNPRA123]

oh my god same with me,can be error in long time ago,but github last update can be create me happy lol

[usirg]

This starts to suck. The thread is over a year old and as far as I could see has gotten no reaction from GitHub. There are two aspects to this that make this very annoying: first, it's bothering lots of people and second, as I pointed out in my earlier post, this should be relatively easy to fix.

One option to potentially get some traction with this, is for someone with an appropriate account type (Pro, Enterprise etc.) to open a support ticket and point this out. I've had success doing that with Atlassian but I only have a free GitHub account myself.

[nielsdt-rabobank]

Good suggestion. We do have the same problem and we do have an enterprise license. So I have created a support ticket.

[usirg]

thanks, much appreciated!

[slifty]

Fully agreed -- folks might also consider checking if anybody in their network might happen to work for github and try to escalate internally somehow.

[leite08]

Another one needing this, here - with enterprise license. Also created a support ticket.

[stuartmackey]

+1

[caindy]

Another +1 into the void

[daltonbr]

Another +1 to keep it going!

[BarbourSmith]

Same here!

[kvij]

+1 super annoying. I am even writing a userscript for it until github gets it together.

[klondikemarlen]

See https://github.com/orgs/community/discussions/11729#discussioncomment-7745019 if you have tampermonkey.

[NatElkins]

Just want to chime in, this also has bitten me several times. Please add this setting!

[lancerinf]

+1 because I felt dumb for even looking it up after not finding the setting in the repo setting, and it turns out it was never an option! :O

[azataiot]

+10000

[timber-they]

+1 how is this not a thing?

[jon-mcclure]

+1 Impacting my team, too. This is very counter-intuitive behavior.

[thescientist13]

Running into this issue as well, would love the option to select a default base branch for forks.

As others mentioned, If the upstream repo is archived could that maybe a way to enable this automatically at least without needing a config option?

[MKL-SebastianLoeffler]

In my opinion, it is a bug that GitHub chooses the original repo as default upstream instead of the own (forked) repo – even if the original one is not archived.

• Best solution would be to make the default upstream configurable per repo.
• Second best solution would be to just fix the default upstream being the own (forked) repo.

[atobiszei]

Just created accidental PR in upstream repository. I would really like to be able to prevent myself from doing the same another time by accident.

[jsoref]

(It's been mentioned before that if you want to avoid this and don't want to wait for GitHub to change the ui, you can use gh pr create ... which lets you set the default repository amongst other things.)

[Nico-Schaefer-2111]

at which point is that mentioned? Maybe I am blind, cause I can't see that option within the documentation you linked..

[jsoref]

gh repo set-default controls which repository is used. Generally the first time you use gh pr (or similar?) in a clone, gh will ask you which remote to use for commands.

[shawnfelix]

+1 this needs to be a priority. Surprised it still isn't an option

[weineran]

Here is a really solid workaround I've been using for a while.

Instead of creating your PR from the web, create it from the command line, like so:

• cd to your repo directory
• Make sure you are on the branch that you want to use as the head ref for the PR.
• Run the gh pr create command like this (including some optional params that I typically use):

gh pr create --base main --assignee <my-username> --label enhancement --fill --web

• This opens a browser tab to the GitHub "Open a pull request" page with all the key info pre-populated. Like this:
  

(Of course you'll need to install the gh CLI if you haven't already. See here: https://github.com/cli/cli)

Background
For several months, I've been working on a project, https://harvestiy.com/, which is forked from ShipFast. Initially I was creating all my PRs from the GitHub web interface and was super annoyed at having to manually change the base ref every time. Then I discovered the gh pr create command. Now life is good 😄 .