Prevent accidental pull requests to upstream when working on a fork

[PeopleInside]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Other

Body

Hi everyone,
I'd like to share a recurring issue I've experienced when working on forks and see if others have encountered the same problem or have suggestions.

Context
I maintain a fork of a Flarum extension:
My fork: https://github.com/PeopleInside/flarum-ext-first-post-approval
Original: https://github.com/clarkwinkelmann/flarum-ext-first-post-approval

My workflow involves creating version branches for testing before tagging a release. I often need to open pull requests within my own fork (from a version branch to my fork's master).

The problem
GitHub's "Compare & pull request" banner and default suggestions almost always default to the upstream repository as the base. As a result, I have accidentally opened pull requests against the original maintainer's repository multiple times. Each accidental PR generates email notifications for the original developer, and when I close them and accidentally open another one, it creates repeated noise.
You can see some of these unintended PRs here:
https://github.com/clarkwinkelmann/flarum-ext-first-post-approval/pulls?q=is%3Apr+is%3Aclosed

I always end up having to manually change the base repository to my own fork, but it's easy to miss, especially when working quickly.
Suggested improvements

I think the following would be very helpful for anyone maintaining an active fork:

• Remember the preferred base repository for pull requests on a per-fork basis, so that GitHub defaults to suggesting PRs within the fork rather than to upstream.
• A repository-level setting to define the default base repository for pull requests (e.g., "self" vs. "upstream").
• A clearer confirmation dialog before creating a pull request, explicitly showing the target repository and branch in a prominent way.

Suppress the "Compare & pull request" banner when the comparison is against the upstream master and the user is working on a long-lived fork.
Has anyone else run into this? Are there any workarounds I might be missing, or is this something that would need to be addressed by GitHub directly?
Thanks in advance for any thoughts or suggestions.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[Levi-o1o1]

As a possible workaround, you may find it safer to create pull requests from the "Pull requests" tab and manually select both repositories and branches rather than relying on the banner suggestion, although I understand that doesn't fully solve the issue.

I'm curious whether other fork maintainers have run into the same problem, especially those who maintain forks long-term rather than using them only for upstream contributions.

[PeopleInside]

Thank you for the message, I'll definitely give it some thought! ❤️🙏🏼

[maheerCodes]

hey @PeopleInside 👋 .
real pain point ,,,i can see exactly what youre describing in the closed prs list on the upstream repo(2.1.0 ,2.0.8 ,2.0.5 etc all closed there). totally get the frustration.

Levi's workaround is the right direction but there's actually a more permanent fix that solves this at the source : ,,,

disable the upstream sync /comparison link entirely .
github determines the default pr base using the fork relationship metadata ,,, but you can change which repo your fork's default branch compares against by going to :

your fork -> settings ->scroll to the bottom-> in older githubb layouts this was "default branch" settings,,but the more reliable method now is:

• go to your fork's branches settings page.
• under your default branch (master),,,there isnt a direct "stop comparing to upstream" toggle unfortunately,, github doesnt expose this directly through settings.

the workaround that actually sticks(better than manual selection each time ):
since you're 53 commits ahead and clearly maintaining this long-term rather than contributing back,,,,id seriouslyy consider detaching the fork relationship entirely.you can request this via github support (they have a "detach fork" process),,once detached ,, your repo becomes fully independent and the "compare across forks" banner disappears completely since github no longer tracks it as a fork of clarkwinkelmann's repo. youd lose the visual"forked from"badge and the easy upstream-merge ui ,,,but since you're clearly diverging significantly (PHP 96% vs their 61%, your own releases/ tags) that trade-off might be worth it.

if you want to keep the fork relationship for occasional upstream merges,,,,,Levi's approach (always use the pulll requests tab ,never the banner)combined with double-checking the base repo dropdown before clicking "create" is really the only current option. agree this should be a per-repo default setting though,,,solid feedback.

[PeopleInside]

Thank you for the message, I'll definitely give it some thought! ❤️🙏🏼

[PeopleInside]

Unfortunately I'm unable to change which repo your fork's default branch because also looking at your instruction I'm unable to find how to do. Ignore the banner is maybe helpful but it' hard also the same behavior seems happen if I use the Pull Request tab as also here I need to remember to manually change from the owner to mine repo.

Unlink the repo maybe possibile also directly from the settings at the bottom of page but I want avoid this for now... also if currently seems the only solution applicable. I hope GitHub will fix this behavior because it create annoying email notification to me but also to the original owner that get a lot of unwanted notification because of this default settings that I don't wont and I cannot change of not every time manually but I forget.

[maheerCodes]

you're right ,,,and i should be straight about it : theres genuinely no settings toggle for this.i was wrong to imply there was a hidden one,,,i went looking again after your reply and confirmed github just doesnt expose a "stop defaulting to upstream" settting anywhere in repo settings. my mistake for suggesting otherwise .
and good catch on the pull requests tab too ,,, youre right that it still defaults the base repo dropdown to upstream even there .it just moves where you have to remember to change it ,,, doesnt remove the need to remember.

so realistically there are only two actual options right now :

1. detach the fork(the one real structural fix),,,this does genuinely remove the upstream comparison entirely since github stops tracking the fork relationship.understand you want to avoid it for now though,, fair enough given you might stilll want to reference / diff against upstream occasionally,
2. a pre-commit /pre-push git hook reminder ,, not a github feature but a local workaround:you could add a pre-push hook in your local repo that just echoes a warning like"DOUBLE CHECK PR BASE REPO"whenever youu push a version branch. wont stop the click ,but adds a deliberate pause before you open the pr from the banner.

honestly though ,,,#2 is a band-aid. youre right that this is a real gap and detaching is currently the only thing that structurally fixes it.

appreciate you pushing back on my first answer rather than just taking it at face value 💙💙💙💙

[PeopleInside]

Thank you, you are very kind. Yes.. face doesn't disturb but I thought a reply was better. Thank you for your help! I reported this GitHub issue behaviour here and also privately to GitHub by reporting with a ticket. I'm sorry to have disturbed so much the original author of the extension that was nice and kind but this kind of behaviour should have a fix or a solution in the future, I hope.

[PeopleInside]

Finally I have unforked every fork repo I manage.
This is not what I want but i still made errors and disturbing original developers so I unforked the repos.
For now no response from GitHub even to the ticket, anyway I will stop to keep project forked because of this issue. That's all.
I really hope they made a fix in the future and will also alert me.

[Fran-B]

How is that accomplished?

[maheerCodes]

hey @PeopleInside 👋 .
sorry it had to come to that ,,,unforking shouldnt have been the only path forward,but at least it permanently solves the accidental-pr problem since theres no upstream relationship left to default to anymore .

glad you also filed it as a real github ticket and not just here,,, thats genuinely the right move for something like this since its a product gap,not user error.hopefully your ticket gets traction evenn without an immediate response.

since your core problem(accidental prs to upstream)is now fully resolved ,,, even if not the way youd have preferred ,, mind marking this thread as answered?itll help other long-term fork maintainers who hit the same issue find this conversation faster,including the detach / unfork option as the only current real fix.

really appreciate you pushing back honestly throughout this thread btw,,,made for a much more useful discussion than if you'd just accepted the first(wrong)answer🩷🩷🩷🩷 .