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

[ALNPRA123]

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

[danielg25]

Are there any specific limitations in the current system that make it difficult for your workflow when dealing with forks and PR targets?

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

[weineran]

For the people who have accidentally opened a PR against an upstream repo, I'm curious what exact workflow you're using to open a PR. GitHub web interface?

Currently working on a browser extension that would prevent accidental PRs, but it will only help if you're using the web interface to open PRs.

Are there other workflows/interfaces that people are using to open PRs where they run into this issue?

[klondikemarlen]

I'm using the web interface, which I've patched with this script: https://github.com/orgs/community/discussions/11729#discussioncomment-10758262. A dedicated plugin would be much nicer!

To my knowledge, the both gh client and vscode support setting the default base repo for pull requests, so I think the web interface is the last commonly used service missing this feature.

• gh option -> gh repo set-default
• vscode option via GitHub Pull Requests -> githubPullRequests.overrideDefaultBranch

[colinvn]

+1 for the web interface

[SpicyLemon]

When I do a git push from my terminal (on a branch that's new to the remote), the resulting output includes a link for creating a PR with the format https://github.com/<org or user>/<repo>/pull/new/<branch>. I command+click on that and the PR creation page opens in my browser.

Every now and then, though, I go to the repo's branches page, find the branch I've been working on and click the "Compare & pull request" button (or click on it in the banner on the main repo page if I pushed it recently enough).

Both routes suffer from the issue at hand; the initial base repository is the upstream one and there's no way to make it default to the repo that I pushed the branch to.

[klondikemarlen]

Interesting ... @SpicyLemon you might be able to adapt that JS script I wrote into a global git hook? I've never actually noticed if git push returned a repo link.

Disclaimer: code translated by ChatGPT o1-preview

~/.git/hooks/post-push

#!/bin/bash

# This is a Git post-push hook script

# Get the current branch name
current_branch=$(git rev-parse --abbrev-ref HEAD)

# Get the repository URL
repo_url=$(git config --get remote.origin.url)

# Extract the repository owner and name from the URL
if [[ "$repo_url" =~ github\.com(:|/)([^/]+)/([^/]+)(\.git)?$ ]]; then
    repo_owner="${BASH_REMATCH[2]}"
    repo_name="${BASH_REMATCH[3]%\.git}"
else
    echo "Cannot parse repository URL: $repo_url"
    exit 1
fi

# Construct the pull request URL
# For example: https://github.com/<repo_owner>/<repo_name>/compare/main...<repo_owner>:<repo_name>:<current_branch>?expand=1
pr_url="https://github.com/${repo_owner}/${repo_name}/compare/main...${repo_owner}:${current_branch}?expand=1"

# Output the pull request URL
echo "Create a pull request by visiting:"
echo "$pr_url"

# Optionally, open the URL in the default web browser
# Uncomment the following lines if you want to automatically open the URL
# if command -v xdg-open &> /dev/null; then
#     xdg-open "$pr_url"
# elif command -v open &> /dev/null; then
#     open "$pr_url"
# fi

[SpicyLemon]

This thread is full of workarounds. They all have their problems, though. Primarily, none of them actually addresses the real problem. Only GitHub can do that, and they apparently don't think its a problem worth fixing.

[jskinne3]

I believe the lack of this feature is breaking GitHub Workflows. Because workflows can only be run from the default branch, they will never run in a forked repo.

If this isn't going to be directly fixed, it would at least be nice to see a warning when one attempts to run a Workflow that cannot run for this reason.

[jsoref]

?
Are you sure you're in the right discussion?
I run workflows in forks all the time. In forks, if you want, you can change the default branch.

[jskinne3]

I would be interested to see this. Can you link me to an open source repo in which I can see Workflows running within a fork?

[klondikemarlen]

I would be interested to see this. Can you link me to an open source repo in which I can see Workflows running within a fork?

@jskinne3
https://github.com/icefoganalytics/internal-data-portal/blob/main/.github/workflows/docker-publish.yml -> release are generated on merge to main -> https://github.com/icefoganalytics/internal-data-portal/releases.

The upstream generates separate releases in https://github.com/ytgov/internal-data-portal/releases.

[klondikemarlen]

Just to be clear ... we are both talking about a github fork, not a git fork here right?

That said, its my understanding that, https://github.com/actions/checkout will let you check out whatever you want be it a branch, tag or SHA.

[jesseplusplus]

Former GitHub engineer and open source maintainer of a long-running fork of mastodon here. I mostly make pull requests against my own fork and occasionally send patches upstream. I echo that the web interface really needs a default base repo setting for pull requests; I've made several embarrassing accidental PRs against the upstream repo, including one just yesterday.

[usirg]

thanks for weighing in, but can you speak to the complete absence of any reaction from GitHub on this matter? I understand that several people from this discussion have opened tickets with their enterprise license. But we've never heard back. The only way to move this forward is to get GitHub's attention somehow. A personal contact to someone well placed would be good. I am note aware of a specific way of requesting changes and gathering support for such requests. But maybe there is and we simply don't know about it? It just feels silly having this discussion for years on a topic that should be fairly easy to solve technically but just doesn't get any attention from the people who can actually change it.

[jesseplusplus]

I have no idea how it works these days, unfortunately. These discussion forums didn't even exist when I worked there; most complaints about features would come in to engineering from emails to support. That may still be the best way to give feedback. I'll definitely be sending an email to support too, and I encourage anyone else with the issue to do the same.

[usirg]

thanks for that!

[Nodens-]

Anyone else with the issue would literally translate to anyone who has ever forked a repo with the intention of working on the fork or diverging from upstream. Which would really be thousands of users. It is frankly quite unbelievable that this has been ignored for so long. The most common case is when you have engineers who have never submitted a PR before on github, trying to submit one to your fork. It is 200% certain that they'll submit it upstream instead and it may take ages for them to even notice if they're busy with their own work and the upstream project is dead.
Apart from fork repo users, upstream repos are also affected by having to deal with the noise and potentially start reviewing commits that could be entirely irrelevant to the upstream project. I once spent 2 hours reviewing a big PR in an upstream C++ project where the code changes did not make much sense. Then I spent another hour writing detailed inline comments, requesting clarifications and changes, only to get a "Ooops sorry, this PR was meant for x's fork". And it's certainly not the user's fault.. how hard is it to expose a setting for this?
Let's all mail support and see if that changes anything.

[stsp]

I asked github's copilot about this, and
he says this:

When you fork a repository on GitHub, the default behavior for creating pull requests (PRs) is to open them against the parent
repository from which it was forked. However, you can change this behavior by creating a pull request template that includes a
default base branch in your forked repository.
...
Add the following content to default.md to set the default base branch to your repository. Replace your-username and your-repo with your GitHub username and repository name, respectively:

---
base: your-username:main
---

<!--
Thank you for your contribution! Please provide a description below of what changes you are making, and why.
-->

## Description

I tried, and it doesn't seem to work.
But maybe I am just doing something wrong?

[usirg]

I only had a quick look but it very much looks like default.md is how GitLab handles default templates for "merge requests and issues". While the GitHub docs don't mention a default.md file nor, more importantly, a setting for the base branch, see:

• Creating a pull request template for your repository
• About issue and pull request templates

Hilarious that this is what Copilot came up with 😁

On the bright side, as shown by GitLab, the pull request templates would be a readily available option to implement a base branch setting.

[stsp]

Hilarious that this is what Copilot came up with 😁

It doesn't surprise me, as you haven't
seen his other bright ideas. :) Like eg
converting binary debs to source debs
before uploading to PPA... And he went
great lengths insisting and elaborating
on such "solutions".

[revitteth]

Hey @github is there any update on this? Really could do with this!

[GooberRF]

Adding my +1 to this. This feature would be extremely valuable.

[afa7789]

+1 to this

Wait we didn't had this @github ? rofl

[afa7789]

Yes. Im working on a fork that probably will never be merged again to the original. Everytime I have to create a PR the base branch is the original repo and not the current repository and end up taking extra clicks which can be easily forgotten to be made. If a default is defined we could as well be let to choose which it will be for the fork.

…

On Sun, Jan 19, 2025, 13:05 Rusty Collier ***@***.***> wrote: Are there any specific limitations in the current system that make it difficult for your workflow when dealing with forks and PR targets? — Reply to this email directly, view it on GitHub <#11729 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGNEMFZPXH7YN5Z6OXIQ4Q32LPEMHAVCNFSM5OY2FIJKU5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCMJYHAZDIMBQ> . You are receiving this because you commented.Message ID: ***@***.***>

[GooberRF]

I'm in the same boat. Working on a fork that will never realistically be merged into the original (and is intended to continue as an independent project). The current system makes using PRs within my fork tedious because I have to always remember to change the target to the base branch of my fork rather than the default of the base branch for the upstream repo (which is 400+ commits behind my fork). This means a very unintuitive extra step in my workflow, and if I miss it, the upstream repo gets a completely garbage PR with an enormous amount of commits that are completely unsuitable for it - then I have to go clean up that mess and close the PR.

Being able to set the default PR merge target for a fork would be ideal, and doesn't seem like it would be a particularly complex feature to implement.

[CaringDev]

Same here... working on a fork that definitely won't be merged, as the base repo is archived and abandoned.

[IvanBelyakoff]

+1, same here. Please add this feature

[Amir-Zucker]

Yep, same here.
Working on a fork that has diverged from the original repo beyond the point where it could ever realistically be merged back.

Not to mention that if you accidentally tap the "compare across forks" button it will only present <master> from <feature branch> even though it actually compare original repo <master> with your forked repo <feature branch>, which is just the same as before and the worst possible interpretation of how it should behave, to the point it feels like GitHub is trolling us.

Tapping that button should activate the compare across forks feature which should be off by default. Even if for some reason GitHub insist on opening the PR by default back to the original repo, tapping that button then should compare branches on your local repository, not just hide the fact that you are comparing branches across different repositories.

Giving the fact that it has been almost 3 years since the original post, I doubt they will ever change it, which is really annoying.

[MaitreyaBuddha]

I should have just used my original repo, now I'm forked 😭

[weineran]

Watch your language around the child repos!

[weineran]

Chrome extension: Safe Pull Request
Earlier in this thread I mentioned that I was working on a Chrome extension to address this problem.

The extension is now ready and available in the Chrome Web Store: https://chromewebstore.google.com/detail/safe-pull-request/lgjhdicdaddeoodpifjdipgooggbojfc

Note that it does require purchasing a license key to function, which you can get here: https://safepullrequest.com/

I think and hope it is good value for the price, but if you have feedback on the price or on anything else about the extension for that matter, feel free to open an issue here: https://github.com/weineran/safepullrequest-feedback/issues Or you can DM me or tag me on X: @ThreeMoonsAreUp

Quick Instructions

• Install the extension from the Chrome Web Store link above.
• Buy a license key from https://safepullrequest.com. There are two tiers. The "personal" tier works on repos that are owned by individual GitHub user accounts but not those owned by organization accounts. The "professional" tier works on both types of repos.
• Click on the extension icon in your browser to open the UI and enter your license key and your GitHub username.
• Once that's done, then when you open a PR from a downstream fork, it will open the PR against that downstream fork by default, not against the upstream "parent" repo.
• Obviously this only works when opening PRs on github.com. If you are opening PRs from command line, see this workaround I posted a while back: https://github.com/orgs/community/discussions/11729#discussioncomment-8609767 and https://github.com/orgs/community/discussions/11729#discussioncomment-9196152

There is a known issue with the extension where if you open a PR from the repo's /branches page, it still opens the PR against the upstream parent. This is a bug. See here: weineran/safepullrequest-feedback#4 So if you usually open PRs from the /branches page (I think this is uncommon), you might want to hold off on purchasing a license until I fix that.

[weineran]

I hear ya. And agree GitHub should just fix it. But in the meantime, figured this extension might help some people enough that they'd be willing to pay for it (ideally with their corporate card).

The TamperMonkey script definitely does the trick as well. Since you were too polite to link to it, here it is, for everyone's convenience: https://github.com/orgs/community/discussions/11729#discussioncomment-7745019

[jjuelotc]

This discussion thread was pretty unanimous with not wanting a third party browser based solution to this problem, let alone one that has a cost associated with it. Nearly every comment on this entire discussion is a voice in agreement asking github to create this feature natively. Please take your sales pitch for a browser extension we don't need somewhere else.

[revitteth]

Popcorn time!

[MaitreyaBuddha]

I agree with disagreeing with this post. It seems to have distracted people from the previous post that was my pun. That and/or it was a very terrible pun. 🍿

[weineran]

No, it was a good pun. That was my bad for distracting the group.

[joewagner]

I'm piling on with a +1 for this feature. I don't want to use an extension, or try to convince all of the team to open PRs through an IDE.

[weineran]

Out of curiosity, is the main objection to using an extension at all? Or is the main objection that the extension is paid?

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