11 ms·

The No.1 reason for me is that it makes you use git like it is supposed to be used: Via email and your MUA. The "pull-request-model" invented by github is an a

The No.1 reason for me is that it makes you use git like it is supposed to be used: Via email and your MUA. The "pull-request-model" invented by github is an abomination of a workflow. Communities stop scaling because of it (see nixos/nixpkgs) because it does not allow horizontal scaling at all - thousands of "PRs" open, nobody feeling responsible and slowdown overall. Having a tool that provides only an "overlay" over the workflow git wants to be used with, and that's what sourcehut is, but not a replacement for it (which is what github is), is refreshing and promising!

throwaway894345 6y ago
Can you elaborate on how sourcehut or other git workflows scale better?
- ddevault 6y ago
  You may find this helpful: https://drewdevault.com/2020/09/02/Linux-development-is-profoundly-distributed.html https://drewdevault.com/2020/09/02/Linux-development-is-prof...
Znafon 6y ago
It's not "an abomination of a workflow", and it's very possible for communities to have difficulties in scaling with a mailing list and have a bus factor of 1 despite plenty of movement on the mailing list. Git also had a git-request-pull command that prepares a mail with the same information that you can find in a pull request on GitHub even before GitHub existed. There is no "one true way" to Git and if organization to adapt their workflow to their needs they can have issues both with mailing lists and the centralised forge model.
ChickeNES 6y ago
> The No.1 reason for me is that it makes you use git like it is supposed to be used: Via email and your MUA. Welp, that puts me off using it entirely sadly. I hate dealing with mailing lists and refuse to contribute to any project that requires dealing with text patches in 2020. Like it or not, the pull request model is simply easier to deal with and is easier for new users to use.
- ddevault 6y ago
  The pull request model is not easier to use, you just already know how to use it. Anyone who maintains a large enough GitHub project can attest that there are many people who don't grok GitHub pull requests, either. If you prefer to use a web-based workflow, then you can both prepare and review patches on our web UI, and they're automatically sent as emails. You don't actually have to interact with email directly at all. And, once you're used to it, pretty much everyone who uses email can assure you that it's much easier to use, much more efficient, and much more scalable than pull requests.
  - ChickeNES 6y ago
    No, it's not unfamiliarity, I have had to use email to manage and submit patches before, and hated it. This just stinks of doing things the old way in cargo cult like fashion. This whole approach, some development in email, some on the web, and some on a disused IRC channel is exactly why projects like Cairo suffer from lack of contributions. Do people really want to deal with text patches in 2020? I appreciate the back-to-basics approach and aesthetics, but srht just seems to be throwing out the baby with the bathwater.
    - ddevault 6y ago
      >is exactly why projects like Cairo suffer from lack of contributions I don't really agree with this. Many projects enjoy a vibrant development community on mailing lists today. Cairo suffers from different issues - and ultimately in Cairo's case it doesn't really matter. Cairo has been "done" for years, it's not the end of the world if it doesn't see much activity. >Do people really want to deal with text patches in 2020? Yes. You'll find many of them in this very thread. SourceHut is a brand-new service, only around for 2 years in alpha, and in 2020 alone it transacted 37,000 emails. There's obviously demand here. One thing that can matter a lot if you're trying out the email workflow is making sure you're using a good client. I made one that I recommend as such: https://aerc-mail.org https://aerc-mail.org. Other good choices include mutt and alpine.
      - 6y ago

throwaway894345 6y ago

Can you elaborate on how sourcehut or other git workflows scale better?

ddevault 6y ago
You may find this helpful: https://drewdevault.com/2020/09/02/Linux-development-is-profoundly-distributed.html https://drewdevault.com/2020/09/02/Linux-development-is-prof...

Znafon 6y ago

It's not "an abomination of a workflow", and it's very possible for communities to have difficulties in scaling with a mailing list and have a bus factor of 1 despite plenty of movement on the mailing list. Git also had a git-request-pull command that prepares a mail with the same information that you can find in a pull request on GitHub even before GitHub existed. There is no "one true way" to Git and if organization to adapt their workflow to their needs they can have issues both with mailing lists and the centralised forge model.

ChickeNES 6y ago

> The No.1 reason for me is that it makes you use git like it is supposed to be used: Via email and your MUA. Welp, that puts me off using it entirely sadly. I hate dealing with mailing lists and refuse to contribute to any project that requires dealing with text patches in 2020. Like it or not, the pull request model is simply easier to deal with and is easier for new users to use.

ddevault 6y ago
The pull request model is not easier to use, you just already know how to use it. Anyone who maintains a large enough GitHub project can attest that there are many people who don't grok GitHub pull requests, either. If you prefer to use a web-based workflow, then you can both prepare and review patches on our web UI, and they're automatically sent as emails. You don't actually have to interact with email directly at all. And, once you're used to it, pretty much everyone who uses email can assure you that it's much easier to use, much more efficient, and much more scalable than pull requests.
- ChickeNES 6y ago
  No, it's not unfamiliarity, I have had to use email to manage and submit patches before, and hated it. This just stinks of doing things the old way in cargo cult like fashion. This whole approach, some development in email, some on the web, and some on a disused IRC channel is exactly why projects like Cairo suffer from lack of contributions. Do people really want to deal with text patches in 2020? I appreciate the back-to-basics approach and aesthetics, but srht just seems to be throwing out the baby with the bathwater.
  - ddevault 6y ago
    >is exactly why projects like Cairo suffer from lack of contributions I don't really agree with this. Many projects enjoy a vibrant development community on mailing lists today. Cairo suffers from different issues - and ultimately in Cairo's case it doesn't really matter. Cairo has been "done" for years, it's not the end of the world if it doesn't see much activity. >Do people really want to deal with text patches in 2020? Yes. You'll find many of them in this very thread. SourceHut is a brand-new service, only around for 2 years in alpha, and in 2020 alone it transacted 37,000 emails. There's obviously demand here. One thing that can matter a lot if you're trying out the email workflow is making sure you're using a good client. I made one that I recommend as such: https://aerc-mail.org https://aerc-mail.org. Other good choices include mutt and alpine.
    - 6y ago