Thanks for the issue @qqingyufeng. It looks like that article needs to be updated -- the dialog to fork a repository will appear when you attempt to push to a repository that you do not have write access to. For reference you should see a dialog that looks like this:

Clicking Fork this Repository will automatically fork the repository to your GitHub account.

Thanks for pointing this out!

Similar to #17195 I have some repositories where forks should have been created but instead they are clones.
I think it is repos I've attempted to fork (in the last year-ish?) via GitHub Desktop that are problematic.
(Or it could be repo clones where I have not bothered to create a feature branch, and just committed to my clone's main branch??)
Regardless neither Gitihub Desktop nor GitHub.com give me an option to 'pull-request' my origin (clone) changes to the upstream (forked) repo, or to sync my fork. Desktop does not recognise that it should be a fork (as I don't have write privileges)

Here is one that works OK.

Here is one that does not (no sync fork line).

Both 'well-behaved' clones/forks and problematic repo pairs have apparently valid looking remote strings of the form...

$ git remote -v
origin  https://github.com/MYNAME/therion.git (fetch)
origin  https://github.com/MYNAME/therion.git (push)
upstream        https://github.com/therion/therion.git (fetch)
upstream        https://github.com/therion/therion.git (push)

So is the documentation in error?
Or is there a bug in GitHub Desktop that has crept in the the last year or so?
Or am I missing something else?

I'd like to be able to 'reconnect of origin repos to their upstreams so I can contribute to said upstreams.
How to get my origin to recognise that it has an upstream from which it was cloned/forked:

• in GitHub Desktop?
• in GitHub.com?

In the meantime what is the best workaround? Only create forks via Github.com, and not GitHub Desktop??

Bruce
(git/hub beginner)

@CaverBruce cloning a repository that you do not have push access to does not automatically create a fork -- you will need to create the fork on github.com and then clone that. However, if you clone a repository that you do not have push access to and then attempt to push to it you will be prompted to create a fork of that repository. The local repository will then become a fork.

The second screenshot you shared does not look like a fork, as it does not have the forked from <repository under the name.

I hope that helps clarify things, but let me know if you have any further questions.

Thanks steveward. What you say makes sense, however for two clone/'fork' pairs of repos I cannot replicate this behaviour. Although I have four clone/fork pairs of repos that are working perfectly afaik for some years.

So I'll take on board that best practice is to fork directly using Github.com.

However to test the Github Desktop route (to fork creation) and recover from my immediate impasse I deleted one repo's github.com clone and removed it from Github Desktop, TortoiseGit and local drive, and started afresh creating a clone using GitHub Desktop.
I then created a new branch and used GitHub Desktop to publish it. It recognised correctly that I didn't have access to upstream and asked to create a fork at CaverBruce. Success, I have now been able to make changes, commit locally and create a pull request with original upstream repo as the target.

Just to test whether 'not creating a new branch' was the cause of my pain, I then deleted the other repo's github clone etc., and again created a new clone using GitHub Desktop.
This time I made the changes directly in main and committed them. On pushing via Desktop I was asked if I wanted to create a fork. So again success, apparently. Although Desktop did not give me the option to create a pull request, so suspicion!
On attempting to sync forks via github.com, it recognises they are not in sync, but presumably as I don't have write privileges to upstream, there is no option for me to sync.

I could however go on to create a pull request via github.com, so success in the end.

It remains a mystery to me what caused the original incarnations of the above two clones not to be able to be converted to or recognised as forks. I feel like the above replicated the likely processes I used to create the problem clones. Perhaps it was because Desktop behaviour has changes due to software updates since they were created, and these broke Desktop's and github.com's 'fork detection' behaviour?

I was happy to delete the above repos and start again, since the changes I wished to make were trivial. If that was not the case, I have been able merge unrelated repositories before using the command line ( merge --allow-unrelated-histories) but this seems a messy way to resolve the @qqingyufeng 's issue, as it will create duplicate very similar histories. So undesirable.

One more question. It seems to me that there must be some setting, remote string perhaps (or github.com setting since fork is not a git construct), that tells a repo that it is a fork of another. Can a user manually access or tweak this setting?

This https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo#configuring-git-to-sync-your-fork-with-the-upstream-repository suggests it is possible(?)

One more question. It seems to me that there must be some setting, remote string perhaps (or github.com setting since fork is not a git construct), that tells a repo that it is a fork of another. Can a user manually access or tweak this setting?

It isn't possibly to move a repository to become a fork of an existing repository, since fork networks on GitHub are a rather complicated thing.

Thanks Steve, that answers my question.