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

[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

[klondikemarlen]

@HenryTen In my case, working on government contracts, we fork the upstream (ytgov) to a local version (icefoganalytics). Then I might create 5-10 PRs against our local branch (icefoganalytics) for various features. After which point, my boss will do a merge to the upstream (ytgov) with a PR showing the various changes all at once. There might be several other groups of contractors working on the same project in their own forks at the same time as us.

The issue with the default of creating PRs against the upstream (ytgov), is that I don't actually have edit rights to that repo, and making a PR against the upstream (ytgov) notifies a bunch of people in a different organization. So every time I mess up and don't remember to override the default, I make my company look bad. Then I have to close the PR and re-create it locally.

The reason we don't create each PR against the upstream (ytgov), is that

1. we need the ability to QA our changes locally
2. the maintainers of the upstream (ytgov) are very hands off, so if we want to integrate dependent PRs as we go, we need to do that in our branch. Most of the features we build are vertical, and need 3-6 dependent PRs to be merged to complete them.

[GabenGar]

Nice response to a bot, bro.

[klondikemarlen]

Hey, if it that bot gets this fixed then I don't mind.

[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

[johnnyshankman]

this is a great proposal.

[axi92]

Nice 💡

[davestewart]

Or, when the fork is created, users could be prompted which setting to use.

If a forked repo is effectively stale, then perhaps a notification could be shown?

Either way, the best option for the users (rather than the creator) of the original repo would be prioritised.

[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

[jsoref]

@jamesmortensen: technically yes.
https://github.com/new/import will accept github.com urls as sources.

It will create a detached fork and avoids you having to create an empty repository, and then push into it, but it won't make the people here happy.

Syncing isn't particularly hard if you do go down this path, although it does kinda ruin discoverability.

You could do some interesting magic where you:

1. create a fork of the original repository
2. rename it to {OWNER}/{REPO}-tracking (you don't have to call it tracking, the idea is to not keep it in {REPO} as you're going to put a real repo there in a moment),
3. use the import feature to create {OWNER}/{REPO} (* this doesn't seem to be exposed by gh)
4. change the metadata on {OWNER}/{REPO}-tracking to link (gh repo edit -h "https://github.com/{OWNER}/{REPO}") to it.
5. archive {OWNER}/{REPO}-tracking
6. If you wanted to, you could have a script that:
   1. fetches from {UPSTREAM}/{REPO}
   2. unarchives {OWNER}/{REPO}-tracking
   3. pushes to {OWNER}/{REPO}-tracking
   4. re-archives {OWNER}/{REPO}-tracking
   5. pushes to {OWNER}/{REPO} with a branch of upstream or similar...

[tim-hilt]

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

[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!!!

[aleclarson]

This is beyond frustrating that Github hasn't fixed this...

[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

[johnnyshankman]

what's the point of fork'ing if i detach the fork?

insanely slow as it requires customer service, the same one that wont escalate this UX issue nearly 2 years later.

thank you for this though.

[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 maintain a website template that people fork to use. The fact that the github UI for pull requests defaults 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 (22 and counting):

[ALNPRA123]

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

[rando2]

Thank you @vincerubinetti, this makes me feel so much better for spamming one of your projects today 😬

[BE-Code]

A template is a perfect example of why this is needed. Especially if the repos using the template want to easily add updates made to the template.

[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.

[ThosRTanner]

:+1 - and I don't want a browser extension for this, because I (and I'm not the only one) don't use chrome / firefox / edge. This is something that needs to be sorted by github not by extension authors.

I mean, it lets you create issues against the forked repository and run workflows against the forked repository but you have to go through hoops to make PRs to fix the issues that have been raised...

[ethagnawl]

The lack of any sort of a response from @github here is baffling. This is clearly a common pain point and, seriously, how long could this possibly take for them to implement? One of the orgs I work with has either a higher tier paid account and I'll see if they're willing to open a ticket about this problem.

My use case, for whatever it's worth: we forked a repo which was making fundamental but experimental changes to the origin repo's application structure and contents. It may be upstreamed one day or both repositories may live on indefinitely. Until we have a better sense of which way things will play out, why should we have to constantly dance around the issue of selecting the target repository when opening a pull request? In our case, I'm not aware of anyone accidentally opening a PR to the wrong repo but the UX of switching the repository in the web UI, waiting for the page to refresh, etc. is worse than it has any reason to be.

[usirg]

couldn't agree more and keeping all available fingers crossed - thanks!

[rosskevin]

We have exactly this issue, and I just spammed the upstream repo with a huge and unnecessary PR. I also don't want to disconnect - I want to be able to get our PR accepted and delete our fork. But for now, we may need to go for some time, or forever, with a forked package.

[revitteth]

Come on GitHub ping ping ping! If I assigned a wasted dev time cost to this, company eyes would be watering and I'd be quick sharp deploying gitlab 🤣

[rsomani95]

@github I feel embarrased for your org reading through this thread. My specific use case is covered above multiple times by multiple devs for over 2 years now. There have been numerous occasions when I've accidentally opened a PR against the origin repo that's no longer maintained by me. Funnily enough, I have the most activity on the origin repo now because of the number of times I've had to close accidental PRs.

The only explanation I would've accepted is that this is not available in the free tier. Sadly, I pay for GitHub enterprise and still have to deal with this nonsense. Get it together and fix it.

[acwo]

My guess is it's a technological debt for @github, and they don't really know how to fix it.

[usirg]

they don't need to know - they can ask Copilot 😁

seriously though - this should be next to trivial to fix, as there is already a default branch setting

at this point, what I find considerably more troubling than this unfixed annoyance is the complete lack of engagement from GitHub - because unless this issue just happens to be an anomaly, it would be truly sad to conclude that this is how they deal with such issues in general

at the very least, I would expect a one-liner saying "sorry guys, we won't deal with this because of xyz" - then we could at least all move on

but oh well - let's hope they get their act together eventually....

@rsomani95 did you reach out to GitHub through your enterprise subscription to try and get some feedback on this point?

[sergioisidoro]

Apparently we need to wait until Github's copilot achieves consciousness, so it (they?) can solve this issue, as it seems too much for a specimen of the human species.

Please save us Github copilot!

[klondikemarlen]

🙏

[ocshawn]

+1 why is. this not a setting

[ladd]

I would also like this!

[MKL-SebastianLoeffler]

The lack of that simple BASIC and NECESSARY setting prevents teams from working with forks while actually needed!

GitHub, please do react! Implementing it is a no-brainer!

[gdlol]

A solution is to use Github API instead of the web UI to create pull request: example

This can be wrapped in a package.json script or something similar so that you can create a pull request with a command like pnpm github pr.

[ethagnawl]

While this is probably helpful for some people/teams, it's a workaround and not a solution.

GitHub really needs to address this in their UI.

[weineran]

In the spirit of workarounds, here is a workaround using the gh command line tool, which some of us on this thread are using: https://github.com/orgs/community/discussions/11729#discussioncomment-9196152

[MKL-SebastianLoeffler]

I sent a bug report to GitHub mentioning this thread.

1. From a foreign repository A create a fork B within your organization.

2. Open a pull request in your fork B. –> The target is wrongfully set to repository A instead of fork B.

[usirg]

thanks, much appreciated! Fingers crossed!

[klondikemarlen]

Interesting note, looks like GitLab added the ability to "change the default merge target" in 2021. See https://gitlab.com/gitlab-org/gitlab/-/merge_requests/58093.

[ethagnawl]

That's definitely something to keep in mind while planning future projects!

[weineran]

How do we get github-actions bot to "submit feedback" like it did on this other discussion thread? https://github.com/orgs/community/discussions/5022#discussioncomment-12576365

[klondikemarlen]

@github-actions[bot] Can you please accept our product feedback? 😉

[whizzzkid]

Yet another feature github team will punt on. FFS guys get a grip on your tech-debt.

Edit: Opened an issue with refined-github: refined-github/refined-github#8391 this is a cosmetic issue and can be fixed client-side.

[logiclrd]

I would love to get a solid answer from GitHub as to why they have, to date, taken no action on this issue.

[weineran]

Since GitHub still hasn’t addressed this issue, I decided to make the Safe Pull Request extension free for personal repos.

As a reminder, the extension will default the base repo to your fork (not the upstream) when opening a PR from the GitHub web UI — so no more accidental PRs against the wrong repo.

Here's the link:
https://chromewebstore.google.com/detail/safe-pull-request/lgjhdicdaddeoodpifjdipgooggbojfc?authuser=0&hl=en

[whizzzkid]

$20 for PROs? just to swap out the base repo?, I'd rather have this in refined-github

[MKL-SebastianLoeffler]

I doubt personal repos will need it. It is an issue for organizations because they need to work with Pull Requests within their own (forked) repo.

[weineran]

$20 for PROs? just to swap out the base repo?, I'd rather have this in refined-github

@whizzzkid Totally open to feedback on the price. I just opened an issue here for discussion: weineran/safepullrequest-feedback#6

Agree would be nice if refined-github offered this feature. Would also be nice if GitHub implemented it themselves.

I doubt personal repos will need it. It is an issue for organizations because they need to work with Pull Requests within their own (forked) repo.

FWIW, I do sometimes fork repos to my personal github, e.g. for personal projects, indie-hacker projects, etc. and I still want my PRs to open against my own repo by default, not the upstream repo. So that's the value of this extension for personal repos.