Is this something the remote can control? I figured it was on the local cloner to decide.

Can’t test it now but wonder if this is changed if it affects the remote name for fresh clones: https://git-scm.com/docs/git-config#Documentation/git-config...

If I clone my fork, I always add the upstream remote straight away. Origin and Upstream could each be github, ambiguous.

GitHub could not name it so, because it's not up to GitHub to choose.

There are places where it does choose, but arguably it makes sense for it to be consistent with what you get when using "git clone".

How is it less confusing when your fork is also on github?

Requiring a fork to open pull requests as an outsider to a project is in itself a idiosyncrasy of GitHub that could be done without. Gitea and Forgejo for example support AGit: https://forgejo.org/docs/latest/user/agit-support/.

Nevertheless, to avoid ambiguity I usually name my personal forks on GitHub gh-<username>.

No, it's a normal feature of Git. If I want you to pull my changes, I need to host those changes somewhere that you can access. If you and I are both just using ssh access to our separate Apache servers, for example, I am going to have to push my changes to a fork on my server before you can pull them.

And of course in Git every clone is a fork.

AGit seems to be a new alternative where apparently you can push a new branch to someone else's repository that you don't normally have access to, but that's never guaranteed to be possible, and is certainly very idiosyncratic.

> in Git every clone is a fork

That's backwards. In Github every fork is just a git clone. Before GitHub commandeered the term "fork' was already in common use and it had a completely different meaning.

As I remember it, it was already in common use with exactly the same denotation; they just removed the derogatory connotation.

Arguably the OG workflow to submit your code is `git send-email`, and that also doesn't require an additional third clone on the same hosting platform as the target repository.

All those workflows are just as valid as the others, I was just pointing out that the way github does it is not the only way it can be done.

Yes, that's true. Or git format-patch.

> Requiring a fork to open pull requests as an outsider to a project is in itself a idiosyncrasy of GitHub that could be done without. Gitea and Forgejo for example support AGit: https://forgejo.org/docs/latest/user/agit-support/.

Ah yes, I'm sure the remote being called "origin" is what confuses people when they have to push to a refspec with push options. That's so much more straightforward than a button "create pull request".

As far as I'm concerned the problem isn't that one is easier than the other. It's that in the github case it completely routes around the git client. With AGit+gitea or forgejo you can either click your "create pull request" button, or make a pull request right from the git client. One is necessarily going to require more information than the other to reach the destination...

It's like arguing that instead of having salad or fries on the menu with your entree they should only serve fries.

agreed, you'd need a second name anyway. and probably "origin" and "upstream" is nicer than "github" and "my-fork" because.. the convention seems like it should apply to all the other git hosts too: codeberg, sourcehut, tfs, etc

Huh. Everyone seems to use "origin" and "upstream". I've been using "origin" and "fork" the whole time.

I use "mine" for my fork.