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!

[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

[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

[jlord]

👋 Hi, hi! Wanted to let the group know that we are investigating this (thank you for this feedback, it's extremely helpful for planning!) and I'll update here when I have some more news ✨

[jdelucaa]

hello!! 👋 looking forward for this fix/improvement! thanks!! 🚀

[slifty]

@jlord wanted to ping on this just in case there happen to be any updates or other context that might give folks a glimmer of hope for the future.

[jlord]

@slifty sadly I have no updates. We've moved things around and the team I was on working on papercuts is no more so this will fall back to the PRs team.

[azataiot]

@jlord is there any updates on this ? 😢

[slifty]

@jlord darn! Sorry to hear it (a team for addressing papercuts sounds like an amazing idea though... huge bummer it got taken out!)

I wonder if someone from the PR team could be pointed to this thread to hop in and give a rough sense of priority?

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

[radekg]

Please provide this setting.

[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

[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

[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

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

[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

[goranb]

Yet another frustrated user who's trying to keep the fork link without having to manually check where I'm pushing my PR to.

Please, fix this.

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

[aleexaandr]

bumping the thread since the absence of such an obvious feature is incredibly frustrating.

[gigamonkey]

Just piling into to this thread to add a +1 to this being a weird hole in the GitHub experience.

[malteish]

So this settings is actually missing? What a shame, really. Being able to select a default base repository in addition to the default base branch would make my work easier!

[corvus-migratorius]

So +1...

[yu7a21]

+1
please fix it...😔

[tt-cricut]

+1

[ghomem]

Wishing to have feedback on this as well. Thank you.

[kapowaz]

Bumping this branch for another reason. I have a fork of a project which contains hundreds of SVG files, and every time I go to create a pull request the number of SVG previews literally causes Safari to hang.

[klondikemarlen]

Have you tried using a different browser? Safari isn't quite on the same level as Chrome/Firefox.
Alternatively, you might be able to fix this with some .gitattributes magic ... something like *.svg linguist-generated=true https://docs.github.com/en/repositories/working-with-files/managing-files/customizing-how-changed-files-appear-on-github? I haven't tested this, but I've used .gitattributes for similar things in the past.

[slifty]

I'm no mod but just wanted to suggest that this sounds like it should be opened and engaged with as a separate issue / discussion (rather than generating notifications for people who are subscribed to the issue that this thread was opened for)

[usirg]

Yeah, the question of this issue has evolved from "set the default repo for a PR" to why GitHub seems to not pay attention.

Previously, I had asked whether there is an enterprise customer reading this who could raise this with their GitHub contact. That should be one way to get some attention for this.

[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

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

[elsiehupp]

It seems like it might be possible to modify this behavior using GitHub Desktop (but apparently not with the GitHub web interface?). I haven't tried a Pull Request after doing this, but hopefully it'll work...

In the GitHub docs, under GitHub Desktop/Contributing and collaborating/Add & clone repos/Clone & fork from Desktop/Managing fork behavior:

Managing fork behavior

You can change how a fork behaves with the upstream repository in GitHub Desktop.

1. In the menu bar, select Repository, then click Repository settings....

2. In the "Repository settings" window, in the left-hand sidebar, click Fork Behavior.

3. Under "I'll be using this fork...", use the radio buttons to select how you want to use the fork.

4. Click Save.

Note that the screenshots (and precise instructions) may be different if you visit the above support page on Windows rather than Mac.

[lobsterkatie]

Neat. I'd be curious to know whether/how this is reflected in .git/config.

[elsiehupp]

It looks like this setting only affects Pull Requests opened from GitHub Desktop, not Pull Requests opened from the GitHub website. So it doesn't fix the underlying issue, but it could still be useful as a temporary workaround.

(I don't know if there is anything similar in the GitHub VS Code extension.)

[ManishParashar0]

As of today this seems to be working as expected again. No more mentions of too many changes.

[ManishParashar0]

As of today this seems to be working as expected again. No more mentions of too many changes.

[caindy]

Another +1 into the void

[stuartmackey]

+1

[lobsterkatie]

This might help: remote.pushDefault in someFork/.git/config

From the git docs:

The remote to push to by default. Overrides branch.<name>.remote for all branches, and is overridden by branch.<name>.pushRemote for specific branches

Admittedly, having each developer need to go in and edit someFork/.git/config after they clone isn't nearly as nice as being able to set it once and forget it, but it's easy enough to throw into a bootstrapping script.

[usirg]

just tested the following:

1. ran this on the clone of a fork:

git config remote.pushdefault origin

following lines were added to .git/config

[remote]
	pushdefault = origin

2. pushed to remote
3. created a branch in the clone, committed some changes and pushed to remote
4. created a PR (using both the GitHub extension for VS Code and the GitHub website, just in case)

Observation in both cases: the target repo is upstream and not origin.

Let me know in case I made a mistake.

Sad but given the docs to be expected.

The thing that I am sad about most though is not this annoying limitation but the fact that even though we read that this is looked at by the dev team, we have no insight at all into how this is going. I mean, even an official confirmation that we are not missing anything and that this is indeed a limitation or an issue in a backlog even with an undefined ETA. any updates maybe, @jlord 😁

[lobsterkatie]

@usirg - Ah, I think you are talking about the compare URL used when opening a PR, which sets the value of the dropdown for the target repo/branch. IOW, you're ultimately trying to get the UI in GH to behave differently?

My problem - the reason I discovered this setting in the first place, IIRC, and what I thought we were talking about here - was that I would do some work in a branch of my fork, run git push, and end up having pushed to a branch in the original repo, not my forked repo (or getting an error because I wasn't allowed to). I also seem to recall suffering from the opposite problem than is being discussed here - I was trying to contribute to someone else's repo via forking, and ended up opening a PR in my fork rather than the original repo.

EDIT: Come to think of it, though, I may have run into that opposite problem (and gotten the behavior you actually desire) because of how I open PRs, which is with a bash function. In case it helps, I've shoved it into a gist: https://gist.github.com/lobsterkatie/d90b135119c8b11860e6bd0608a4d55d.

[usirg]

@lobsterkatie - thanks for pointing out the /compare feature used by github when creating a PR. I had not paid attention to this before.

This means that changing the base repo for a PR just requires minimal modification of this URL. Not exactly surprising, given how GitHub generally works but good news in the sense that the change desired by many here would be very easy to implement. Specifically, the authors of VS Code's GitHub Pull Requests and Issues extension could probably introduce a per-workspace base repo setting independently of GitHub supporting this on their end.

To answer your question: what I was proposing is not just different UI behavior, although that's not far off. I was suggesting a per-repo setting for the default base repo. Just like the one for the default branch, mentioned in my initial post almost at the top.

The scenario you describe is different from the original question and my reply to it. My last post above was just to confirm that the suggestion made just before doesn't solve the problem at hand.

I had a brief look at your bash script and it seems to me that it would indeed do what everyone is asking for here. This is as expected, since you construct the URL to open the PR as per your requirements. Thing is that we want this as configurable behavior on GitHub and personally, I want to see this working in VS Code too.

[lobsterkatie]

The scenario you describe is different from the original question and my reply to it.

Yup, I get that. I was just explaining how I got to the setting I was mentioning.

Anyway, you're right that neither of my solutions solves this at the GH level, nor in the VSCode extension. My guess is you'd get more traction trying to convince the extension authors to add a preference than getting GH itself to implement the change, but who knows. I wish you luck regardless. 🙂

[usirg]

Agreed, if I find a minute, I'll hit up the extension authors. And thanks, I appreciate that 😁

[jsoref]

Fwiw, what I do is I have:

upstream -> personal fork -> org fork

I do my work in org fork. Worst case, I accidentally create a PR to my personal fork.

I have a script which sets this up (it also changes the default branch of both of my forks and adds some groups and other stuff).