4 ms·

> The service [...] doesn't force you to a particular workflow. I've never actually used it, but isn't that exactly what it does? As far as I know, it only all

> The service [...] doesn't force you to a particular workflow. I've never actually used it, but isn't that exactly what it does? As far as I know, it only allows submitting patches using emails, not using the "pull request"/"merge request"/etc workflow of most other big hosted Git solutions. But it's very possible I just don't have the whole picture here.

vnorilo 4y ago
You are not wrong - there is no web UI for pull requests or merge checks. However the features it does have are simple and thus easily interoperable and composable. There's no push to adopt ever more interlocked services or upsell premium features. Like a nice buffet that just does not have a particular (albeit popular) dish on offer. Where you can bring your own bottle or even an appetizer and nobody will mind.
jefurii 4y ago
Sourcehut is designed to operate the way Git itself operates, and the way the Linux kernel project uses it. In other words, the way it was designed to be used, not the "embrace, extend, extinguish" way that Github uses to insert itself into the process.
- meibo 4y ago
  Or most git hosting solutions. Gitea and Gitlab do exactly the same thing, gitea even looks exactly like GitHub, works the same way, and can be hosted on pretty much any machine. It might be GitHub that popularized this, but it made open source more accessible to a lot of people and a majority of developers clearly get something out of it.
  - jefurii 4y ago
    I should have written more clearly: Github's pull-request workflow is regarded by some (obviously including myself) to be the "extend" part of an "embrace, extend, extinguish" play. In other words, 1) embrace Git, 2) extend it using a Github-only feature and encouraging an entire generation of developers to think that you can't use Git without pull-requests, 3) making it some sort of proprietary product. IIRC Sourcehut was Drew's way to develop a Git hosting solution that integrated the Linux kernel project's workflow. The idea being that this is a completely open-source project that uses open standards, i.e. email, rather than proprietary things like pull-request. He wrote a great article on the email-driven workflow: https://drewdevault.com/2018/07/02/Email-driven-git.html https://drewdevault.com/2018/07/02/Email-driven-git.html You're right, though, Github has done a service to the open-source community, and nobody forces you to use pull-requests.
    - woojoo666 4y ago
      Pull-requests don't have to be proprietary. We just need a standard format. I'm not opposed to using email, but right now the UX/UI looks far too lacking. Perhaps Sourcehut could also release an email client specifically for viewing pull requests, but until then I think it will be difficult to adopt
      - sreevisakh 4y ago
        I know it's a bit late to raise this, but you may find it relevant. > Pull-requests don't have to be proprietary. We just need a standard format. A standard format for pull requests actually exists - that too as part of git itself [1]. Github decided to just redefine the term like they did with 'forking'. Torvalds was pretty annoyed with this [2]: > Git comes with a nice pull-request generation module, but github > instead decided to replace it with their own totally inferior version. > As a result, I consider github useless for these kinds of things. While git's PR is designed primarily for email, it can be shared on any medium of text communication. Git's PR can also be made from any random git host, as long as the changes are hosted there. This makes it immediately usable for almost every hosted git repo - especially for sourcehut. No registration required. > I'm not opposed to using email, but right now the UX/UI looks far too lacking. Again, a problem with current solutions. Most email clients, especially web clients like gmail are terrible for text mails, threaded views, proper quoting, etc - all of which are necessary for a clean email-based workflow. You have to use something like mutt or astroid, and email workflow becomes immediately more enjoyable. While that's what we have now, it doesn't have to end there. Someone could come up with flashy GUI or web interface that's as pleasing as Github's and email workflow will actually become more attractive than Github's. > Perhaps Sourcehut could also release an email client specifically for viewing pull requests Sourcehut is actually working on an email client suited for email workflows, called aerc [3]. > but until then I think it will be difficult to adopt From personal experience, I find adopting email workflow with neomutt or aerc much easier than adopting git itself. Though rebasing is not a strict requirement for email workflow, email patches look janky without it. Learning rebasing is the hard part, not mailing and applying the patches. But the skill to rebase makes your contributions immediately better everywhere - not just for email patches. [1] https://www.git-scm.com/docs/git-request-pull https://www.git-scm.com/docs/git-request-pull [2] https://github.com/torvalds/linux/pull/17#issuecomment-5654674 https://github.com/torvalds/linux/pull/17#issuecomment-56546... [3] https://aerc-mail.org/ https://aerc-mail.org/

vnorilo 4y ago

You are not wrong - there is no web UI for pull requests or merge checks. However the features it does have are simple and thus easily interoperable and composable. There's no push to adopt ever more interlocked services or upsell premium features. Like a nice buffet that just does not have a particular (albeit popular) dish on offer. Where you can bring your own bottle or even an appetizer and nobody will mind.

jefurii 4y ago

Sourcehut is designed to operate the way Git itself operates, and the way the Linux kernel project uses it. In other words, the way it was designed to be used, not the "embrace, extend, extinguish" way that Github uses to insert itself into the process.

meibo 4y ago
Or most git hosting solutions. Gitea and Gitlab do exactly the same thing, gitea even looks exactly like GitHub, works the same way, and can be hosted on pretty much any machine. It might be GitHub that popularized this, but it made open source more accessible to a lot of people and a majority of developers clearly get something out of it.
- jefurii 4y ago
  I should have written more clearly: Github's pull-request workflow is regarded by some (obviously including myself) to be the "extend" part of an "embrace, extend, extinguish" play. In other words, 1) embrace Git, 2) extend it using a Github-only feature and encouraging an entire generation of developers to think that you can't use Git without pull-requests, 3) making it some sort of proprietary product. IIRC Sourcehut was Drew's way to develop a Git hosting solution that integrated the Linux kernel project's workflow. The idea being that this is a completely open-source project that uses open standards, i.e. email, rather than proprietary things like pull-request. He wrote a great article on the email-driven workflow: https://drewdevault.com/2018/07/02/Email-driven-git.html https://drewdevault.com/2018/07/02/Email-driven-git.html You're right, though, Github has done a service to the open-source community, and nobody forces you to use pull-requests.
  - woojoo666 4y ago
    Pull-requests don't have to be proprietary. We just need a standard format. I'm not opposed to using email, but right now the UX/UI looks far too lacking. Perhaps Sourcehut could also release an email client specifically for viewing pull requests, but until then I think it will be difficult to adopt
    - sreevisakh 4y ago
      I know it's a bit late to raise this, but you may find it relevant. > Pull-requests don't have to be proprietary. We just need a standard format. A standard format for pull requests actually exists - that too as part of git itself [1]. Github decided to just redefine the term like they did with 'forking'. Torvalds was pretty annoyed with this [2]: > Git comes with a nice pull-request generation module, but github > instead decided to replace it with their own totally inferior version. > As a result, I consider github useless for these kinds of things. While git's PR is designed primarily for email, it can be shared on any medium of text communication. Git's PR can also be made from any random git host, as long as the changes are hosted there. This makes it immediately usable for almost every hosted git repo - especially for sourcehut. No registration required. > I'm not opposed to using email, but right now the UX/UI looks far too lacking. Again, a problem with current solutions. Most email clients, especially web clients like gmail are terrible for text mails, threaded views, proper quoting, etc - all of which are necessary for a clean email-based workflow. You have to use something like mutt or astroid, and email workflow becomes immediately more enjoyable. While that's what we have now, it doesn't have to end there. Someone could come up with flashy GUI or web interface that's as pleasing as Github's and email workflow will actually become more attractive than Github's. > Perhaps Sourcehut could also release an email client specifically for viewing pull requests Sourcehut is actually working on an email client suited for email workflows, called aerc [3]. > but until then I think it will be difficult to adopt From personal experience, I find adopting email workflow with neomutt or aerc much easier than adopting git itself. Though rebasing is not a strict requirement for email workflow, email patches look janky without it. Learning rebasing is the hard part, not mailing and applying the patches. But the skill to rebase makes your contributions immediately better everywhere - not just for email patches. [1] https://www.git-scm.com/docs/git-request-pull https://www.git-scm.com/docs/git-request-pull [2] https://github.com/torvalds/linux/pull/17#issuecomment-5654674 https://github.com/torvalds/linux/pull/17#issuecomment-56546... [3] https://aerc-mail.org/ https://aerc-mail.org/