5 ms·

GitHub's greatest win has been good UX. They didn’t need to convince people much.

by LudwigNagasena 2y ago

xigoi 2y ago
You mean the UX where you have to make an entire fork of a project in order to add one line of code?
- pindab0ter 2y ago
  What would the alternative be, as you can't just edit someone else's repo? Besides just cloning it and making the change locally, of course.
  - aftbit 2y ago
    IMO the alternative would be for GitHub to have a lightweight process for creating a PR that doesn't require me to copy the project into my namespace.
  - xigoi 2y ago
    Sending a patch to the maintainer.
    - MaxBarraclough 2y ago
      Right. Email can be used for this. This is how git was originally meant to be used, and this model is still used by the Linux kernel. See also the SourceHut forge software, which is built around this model. * https://git-send-email.io/ https://git-send-email.io/ * https://drewdevault.com/2022/07/25/Code-review-with-aerc.html https://drewdevault.com/2022/07/25/Code-review-with-aerc.htm...
  - Sesse__ 2y ago
    > What would the alternative be, as you can't just edit someone else's repo? git push directly to the repository, in a separate branch namespace. This is how e.g. Gerrit works (pushing to a special ref makes a review, which is essentially the same as a pull request). > Besides just cloning it and making the change locally, of course. With GitHub, you cannot do that and get a PR out in the other end. You _must_ fork the repository into your own user/organization, push to that and then send a PR from that.
    - unshavedyak 2y ago
      > git push directly to the repository, in a separate branch namespace. This is how e.g. Gerrit works (pushing to a special ref makes a review, which is essentially the same as a pull request). What's the material difference? They build special mechanisms to provide access control for sub namespaces, which sound a lot like "forks". Also i have no clue on their backend (iirc this info is researchable tho), but i wouldn't be surprised if functionally that is exactly how they do it anyway. It's all content addressed, i doubt they pay 2x the storage anytime you fork a repo right?
      - saurik 2y ago
        The big difference is how it is organized to the users viewing it. My GitHub account is littered with old forks of repositories I created just to submit one line patches; and despite the pull request to a repository in some sense being data relating to the history of that project -- certainly the discussion is all organized under that project -- if the original person actually removes fork to garbage collect their namespace the commits referenced in that pull request just disappear. Meanwhile, despite people now using the word "fork" for this purpose due to GitHub, there is actual value in being able to search for actual forks of a project--things that people are choosing to publicly distribute and maybe maintain themselves--rather than seeing a thousand repositories which exist only for the purpose of contributing a single patch (or, though this is another topic, people making the metaphorical equivalent of a "backup copy" within the strange set of semantics and ownership that is GitHub).
    - jagged-chisel 2y ago
      > … git push directly to the repository Then we have a security problem or two.
      - commodoreboxer 2y ago
        You cut off the important part: > in a separate branch namespace So not really. It's a special branch path that only exists for opening PRs, and doesn't do anything other than opening a PR. Yes, they share an object space, but so do forks in the first place, so any security issues with this flow are the same ones in the fork-PR flow. You can check out this which covers the whole flow: https://git-repo.info/en/2020/03/agit-flow-and-git-repo/ https://git-repo.info/en/2020/03/agit-flow-and-git-repo/ Or for a simpler overview, look at Gitea/Forgejo's implementation: https://forgejo.org/docs/latest/user/agit-support/ https://forgejo.org/docs/latest/user/agit-support/
- rurban 2y ago
  This entire github fork is still cheaper than a forked process on windows.
  - xigoi 2y ago
    But then when you find an unmaintained project and want to find out if it has a maintained fork, you have to browse through hundreds of forks that were created just to submit one patch.
    - mdaniel 2y ago
      > hundreds of forks that were created just to submit one patch. Or, worse (IMHO) when they created the fork to house a patch - sometimes a meaningful feature, bugfix, or security fix - and then left it because the submission process was too onerous to bother. Onerous can also include never getting the PR reviewed, too, which is far more damaging (IMHO) because it disincentivizes future contributions, too I actually would love an "implied PR" view of the forks which would enable quickly filtering out the -0,+0 "shallow forks" from the -50,+2000 "oh, that's likely doing something interesting" ones, provided it has the sane ?w=0 to hide forks that felt it necessary to push up simple reformatting changes
- ajross 2y ago
  It's a shared/copy-on-write backend. An "entire fork" consists of 20-byte commit ID and whatever metadata identifies the owner and organization, and you create the "entire fork" in the UX by clicking on a single button. I don't understand the criticism here, do you just not like the use of the word "fork" because it implies a copy that doesn't exist?
  - xigoi 2y ago
    I don’t like that it appears in the list of forks, making it hard to find actual forks.
  - carom 2y ago
    Not doubting you, but do you have a source where I could read about this? I feel that would create some wild problems if the original repository was deleted. Edit: I guess they would just not delete the data if there were more references to it.

GitHub's greatest win has been good UX. They didn’t need to convince people much.

xigoi 2y ago

You mean the UX where you have to make an entire fork of a project in order to add one line of code?

pindab0ter 2y ago
What would the alternative be, as you can't just edit someone else's repo? Besides just cloning it and making the change locally, of course.
- aftbit 2y ago
  IMO the alternative would be for GitHub to have a lightweight process for creating a PR that doesn't require me to copy the project into my namespace.
- xigoi 2y ago
  Sending a patch to the maintainer.
  - MaxBarraclough 2y ago
    Right. Email can be used for this. This is how git was originally meant to be used, and this model is still used by the Linux kernel. See also the SourceHut forge software, which is built around this model. * https://git-send-email.io/ https://git-send-email.io/ * https://drewdevault.com/2022/07/25/Code-review-with-aerc.html https://drewdevault.com/2022/07/25/Code-review-with-aerc.htm...
- Sesse__ 2y ago
  > What would the alternative be, as you can't just edit someone else's repo? git push directly to the repository, in a separate branch namespace. This is how e.g. Gerrit works (pushing to a special ref makes a review, which is essentially the same as a pull request). > Besides just cloning it and making the change locally, of course. With GitHub, you cannot do that and get a PR out in the other end. You _must_ fork the repository into your own user/organization, push to that and then send a PR from that.
  - unshavedyak 2y ago
    > git push directly to the repository, in a separate branch namespace. This is how e.g. Gerrit works (pushing to a special ref makes a review, which is essentially the same as a pull request). What's the material difference? They build special mechanisms to provide access control for sub namespaces, which sound a lot like "forks". Also i have no clue on their backend (iirc this info is researchable tho), but i wouldn't be surprised if functionally that is exactly how they do it anyway. It's all content addressed, i doubt they pay 2x the storage anytime you fork a repo right?
    - saurik 2y ago
      The big difference is how it is organized to the users viewing it. My GitHub account is littered with old forks of repositories I created just to submit one line patches; and despite the pull request to a repository in some sense being data relating to the history of that project -- certainly the discussion is all organized under that project -- if the original person actually removes fork to garbage collect their namespace the commits referenced in that pull request just disappear. Meanwhile, despite people now using the word "fork" for this purpose due to GitHub, there is actual value in being able to search for actual forks of a project--things that people are choosing to publicly distribute and maybe maintain themselves--rather than seeing a thousand repositories which exist only for the purpose of contributing a single patch (or, though this is another topic, people making the metaphorical equivalent of a "backup copy" within the strange set of semantics and ownership that is GitHub).
  - jagged-chisel 2y ago
    > … git push directly to the repository Then we have a security problem or two.
    - commodoreboxer 2y ago
      You cut off the important part: > in a separate branch namespace So not really. It's a special branch path that only exists for opening PRs, and doesn't do anything other than opening a PR. Yes, they share an object space, but so do forks in the first place, so any security issues with this flow are the same ones in the fork-PR flow. You can check out this which covers the whole flow: https://git-repo.info/en/2020/03/agit-flow-and-git-repo/ https://git-repo.info/en/2020/03/agit-flow-and-git-repo/ Or for a simpler overview, look at Gitea/Forgejo's implementation: https://forgejo.org/docs/latest/user/agit-support/ https://forgejo.org/docs/latest/user/agit-support/
rurban 2y ago
This entire github fork is still cheaper than a forked process on windows.
- xigoi 2y ago
  But then when you find an unmaintained project and want to find out if it has a maintained fork, you have to browse through hundreds of forks that were created just to submit one patch.
  - mdaniel 2y ago
    > hundreds of forks that were created just to submit one patch. Or, worse (IMHO) when they created the fork to house a patch - sometimes a meaningful feature, bugfix, or security fix - and then left it because the submission process was too onerous to bother. Onerous can also include never getting the PR reviewed, too, which is far more damaging (IMHO) because it disincentivizes future contributions, too I actually would love an "implied PR" view of the forks which would enable quickly filtering out the -0,+0 "shallow forks" from the -50,+2000 "oh, that's likely doing something interesting" ones, provided it has the sane ?w=0 to hide forks that felt it necessary to push up simple reformatting changes
ajross 2y ago
It's a shared/copy-on-write backend. An "entire fork" consists of 20-byte commit ID and whatever metadata identifies the owner and organization, and you create the "entire fork" in the UX by clicking on a single button. I don't understand the criticism here, do you just not like the use of the word "fork" because it implies a copy that doesn't exist?
- xigoi 2y ago
  I don’t like that it appears in the list of forks, making it hard to find actual forks.
- carom 2y ago
  Not doubting you, but do you have a source where I could read about this? I feel that would create some wild problems if the original repository was deleted. Edit: I guess they would just not delete the data if there were more references to it.