4 ms·

I always thought it would have been better, and less confusing for newcomers, if GitHub had named the default remote “github”, instead of origin, in the example

I always thought it would have been better, and less confusing for newcomers, if GitHub had named the default remote “github”, instead of origin, in the examples.

masklinn 1y ago
How is it less confusing when your fork is also on github?
- grimgrin 1y ago
  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
  - nicoburns 1y ago
    Huh. Everyone seems to use "origin" and "upstream". I've been using "origin" and "fork" the whole time.
    - masklinn 1y ago
      I use "mine" for my fork.
- matrss 1y ago
  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/ https://forgejo.org/docs/latest/user/agit-support/. Nevertheless, to avoid ambiguity I usually name my personal forks on GitHub gh-<username>.
  - masklinn 1y ago
    > 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/ 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".
    - ratmice 1y ago
      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.
  - kragen 1y ago
    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.
    - matrss 1y ago
      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.
tobylane 1y ago
If I clone my fork, I always add the upstream remote straight away. Origin and Upstream could each be github, ambiguous.
pwdisswordfishy 1y ago
GitHub could not name it so, because it's not up to GitHub to choose.
- seba_dos1 1y ago
  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".
mckn1ght 1y ago
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.txt-checkoutdefaultRemote https://git-scm.com/docs/git-config#Documentation/git-config...

I always thought it would have been better, and less confusing for newcomers, if GitHub had named the default remote “github”, instead of origin, in the examples.

masklinn 1y ago

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

grimgrin 1y ago
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
- nicoburns 1y ago
  Huh. Everyone seems to use "origin" and "upstream". I've been using "origin" and "fork" the whole time.
  - masklinn 1y ago
    I use "mine" for my fork.
matrss 1y ago
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/ https://forgejo.org/docs/latest/user/agit-support/. Nevertheless, to avoid ambiguity I usually name my personal forks on GitHub gh-<username>.
- masklinn 1y ago
  > 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/ 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".
  - ratmice 1y ago
    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.
- kragen 1y ago
  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.
  - matrss 1y ago
    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.

tobylane 1y ago

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

pwdisswordfishy 1y ago

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

seba_dos1 1y ago
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".

mckn1ght 1y ago

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.txt-checkoutdefaultRemote https://git-scm.com/docs/git-config#Documentation/git-config...