There is little difference between a tag and a branch in git. There is just the convention that tags reference the same commit forever, while branches move.

On github forks are part of the same physical repository. You could imagine that each logical repository is just a namespace for branches and tags, backed by the same physical repository.

I do consider the warning a bug if github, it should check both tags and branches for commits which are to be considered part of a logical repository.

Git doesn't have a concept of "fork".

GitHub uses this metaphor, and, as another commenter already aptly described, it could be nothing more than a fancy name for namespaced branches, on the server side.

On the client side, "forks" are usually different repository clones with different remotes and a "coincidentally" shared history.

But you can also map forked repos to multiple remotes of the same repository for example, instead of folders.

Assuming that forks would live in separate clones/blobs on the server is not really based on anything, so I think the warning is a good middle ground between explaining what forks are and how they handle them, and giving actionable advice.

It's also better suited for PR:

"Fork me on GitHub"

vs

"Branch and push your own clone on GitHub, using our shared blob optimizations".

I think the warning is clear and there's nothing misleading about it, but others have already pointed this out and git can be tricky.

It's so good at providing the right level of abstraction to everyone though, it seems!

Similarly, GitHub invented the term "Pull Request" (aka PR, lol).

Not a git-owned term.

But "merge request" isn't a Git primitive either!

And, with Forks and Pull Requesrs, GitHub made a particular workflow in Git approachable to anyone!

I love GitLab, but people get confused by Merges, myself included, so the GH-enabled workflow of favoring ff-only merges, without merge commits, with quadi-linear history, became the norm and helped Git succceed!

But I also appreciate being able to do all kinds of different workflows.

So PRs were positive-sum PR at the time, I'd say. When they became popular, I was still taught Subversion and CVS at uni, alongside Git as "the new thing". Ar that time, many people considered the older systems simpler, and pondered SVN as the most reasonable middle ground between CVS and the decentralized concept of Git!

It can mean either, it's a consequence of how github optimized their backend storage so a 100 forks of a repo initially take up the same space as 0 forks

main (or master) is just another branch to git.