very good sir,good work for this

this is a great proposal.

Nice 💡

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.

Curious to know if there are any progress on this?

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.

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

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

PLEASE!!!

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

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

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

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

@jlord is there any updates on this ? 😢

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

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

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

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

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.

I might add a literal yes/no screenshot to my template's docs, or I maybe a link to the screenshot in the pull_request_template.md. We'll see how much it helps!

psd.zip

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.

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

thanks, much appreciated!

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

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

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

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.

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 🤣

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.

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.

thanks for that!

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.

also not sure why they ask to delete the fork when just renaming it works and is safer. You can delete it later after the new repo is confirmed to be working correctly

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

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

Nice!

There is also this TamperMonkey script written by @klondikemarlen: https://github.com/orgs/community/discussions/11729#discussioncomment-10758262
I used this ⬆️ for a while and it worked nicely.

And of course there is also the Chrome Extension I built (free for personal-owned repos, paid for organization-owned repos): safepullrequest.com

Oh, clever :-) I ought to have checked. Haha :-) Ah well. Don't mind an evening of coding.

Haven't tried yours yet, but it seems like it might have some additional features beyond what the other script had. So yeah, definitely not a waste of an evening ;)

This isn't really a solution because what we are asking for is a way to change this default on the repo in github so it works for all users in the browser or any git interface. IDE specific plugins are just more evidence that people what this feature.

did not say it's a solution either😅

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.

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)

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.

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

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.

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