3 ms·

So... git's original design

JoshTriplett 8mo ago
No. Git is not a web-based GUI capable of managing users and permissions, facilitating the creation and management of repositories, handling pull requests, handling comments and communication, doing CI, or a variety of other tasks that sites like Codeberg and Forgejo and GitLab and GitHub do. If you don't want those things, that's fine, but that isn't an argument that git subsumes them.
- shakna 8mo ago
  Git was published with compatibility with a federated system supporting almost all of that out of the box - email. Sure, the world has pretty much decided it hates the protocol. However, people _were_ doing all of that.
  - JoshTriplett 8mo ago
    People were doing that by using additional tools on top of git, not via git alone. I intentionally only listed things that git doesn't do. There's not much point in observing "but you could have done those things with email!". We could have done them with tarballs before git existed, too, if we built sufficient additional tooling atop them. That doesn't mean we have the functionality of current forges in a federated model, yet.
    - greyface- 8mo ago
      `git send-email` and `git am` are built into Git, not additional tools.
      - JoshTriplett 8mo ago
        That doesn't cover tracking pull requests, discussing them, closing them, making suggestions on them... Those exist (badly and not integrated) as part of additional tools such as email, or as tasks done manually, or as part of forge software. I don't think there's much point in splitting this hair further. I stand by the original statement that I'd love to see federated pull requests between forges, with all the capabilities people expect of a modern forge.
        heliumtera 8mo ago
        What is a forge? What is a modern forge? What is a pull request? There is code or repository, there is a diff or patch. Everything else your labeling as pull request is unknown, not part of original design, debatable.
        JoshTriplett 8mo ago
        Sorry to hear that you don't see the value in it. Many others do.
        heliumtera 8mo ago
        It's not what I meant. GitHub style pull request is not part of the original design. What aspects and features you want to keep, and what exactly you say many others are interested in? We don't even know what a forge is. Let alone a modern one.
        deleted 8mo ago
        [deleted]
        qdotme 8mo ago
        I think people (especially those who joined the internet after the .com bubble) underestimate the level of decentralization and federation coming with the old-school (pre web-centric mainframe-like client mentality) protocols such as email and Usenet and maybe even IRC. Give me “email” PR process anytime. Can review on a flight. Offline. Distraction free. On my federated email server and have it work with your federated email server. And the clients were pretty decent, at running locally. And it still works great for established projects like Linux Kernel etc. It’s just pain to set up for a new project, compared to pushing to some forge. But not impossible. Return the intentionality of email. With powerful clients doing threading, sorting, syncing etc, locally.
        JoshTriplett 8mo ago
        I'm older than the web. I worked on projects using CVS, SVN, mercurial, git-and-email, git-with-shared-repository, and git-with-forges. I'll take forges every time, and it isn't even close. It's not a matter of not having done it the old way, it's a matter of not wanting to do it again.

No. Git is not a web-based GUI capable of managing users and permissions, facilitating the creation and management of repositories, handling pull requests, handling comments and communication, doing CI, or a variety of other tasks that sites like Codeberg and Forgejo and GitLab and GitHub do. If you don't want those things, that's fine, but that isn't an argument that git subsumes them.

shakna 8mo ago
Git was published with compatibility with a federated system supporting almost all of that out of the box - email. Sure, the world has pretty much decided it hates the protocol. However, people _were_ doing all of that.
- JoshTriplett 8mo ago
  People were doing that by using additional tools on top of git, not via git alone. I intentionally only listed things that git doesn't do. There's not much point in observing "but you could have done those things with email!". We could have done them with tarballs before git existed, too, if we built sufficient additional tooling atop them. That doesn't mean we have the functionality of current forges in a federated model, yet.
  - greyface- 8mo ago
    `git send-email` and `git am` are built into Git, not additional tools.
    - JoshTriplett 8mo ago
      That doesn't cover tracking pull requests, discussing them, closing them, making suggestions on them... Those exist (badly and not integrated) as part of additional tools such as email, or as tasks done manually, or as part of forge software. I don't think there's much point in splitting this hair further. I stand by the original statement that I'd love to see federated pull requests between forges, with all the capabilities people expect of a modern forge.
      - heliumtera 8mo ago
        What is a forge? What is a modern forge? What is a pull request? There is code or repository, there is a diff or patch. Everything else your labeling as pull request is unknown, not part of original design, debatable.
        JoshTriplett 8mo ago
        Sorry to hear that you don't see the value in it. Many others do.
        heliumtera 8mo ago
        It's not what I meant. GitHub style pull request is not part of the original design. What aspects and features you want to keep, and what exactly you say many others are interested in? We don't even know what a forge is. Let alone a modern one.
        deleted 8mo ago
        [deleted]
      - qdotme 8mo ago
        I think people (especially those who joined the internet after the .com bubble) underestimate the level of decentralization and federation coming with the old-school (pre web-centric mainframe-like client mentality) protocols such as email and Usenet and maybe even IRC. Give me “email” PR process anytime. Can review on a flight. Offline. Distraction free. On my federated email server and have it work with your federated email server. And the clients were pretty decent, at running locally. And it still works great for established projects like Linux Kernel etc. It’s just pain to set up for a new project, compared to pushing to some forge. But not impossible. Return the intentionality of email. With powerful clients doing threading, sorting, syncing etc, locally.
        JoshTriplett 8mo ago
        I'm older than the web. I worked on projects using CVS, SVN, mercurial, git-and-email, git-with-shared-repository, and git-with-forges. I'll take forges every time, and it isn't even close. It's not a matter of not having done it the old way, it's a matter of not wanting to do it again.