That's so true, but I agree with sneak here (did I just write that?). If my code is on GitHub or GitLab or Gitea or whatever, and I want to work on it with a friend, I can invite them to join me on a website using a workflow similar to 1,000 other not-source-code-related collaboration tools. It's damn near impossible to talk someone into joining an email-based process unless that's something they've already been doing elsewhere. Look at the git-send-email docs[0] which talk about configuring SMTP auth. Followup question from the new person I'd be trying to rope in: "I dunno, my work uses Outlook. What's SMTP?"
If someone contended that SourceHut optimizes for devs who've been writing Linux kernel code for 25 years, so you weed out all the newbs and can get the hardened veterans involved in your project, I could buy that. I'd disagree that it's what I'd want for my project, but to each their own. I couldn't recommend it as an alternative to other services that require participants to know how to use a web browser.
Once you learn the git-send-email flow, it is a lot better, especially for distributed development.
With the PR flow, people need to sign up to the website, create a fork, clone the repo, make their changes, go into a slow web ui etc. It mostly works because everyone is on Github. However, even that solution sucks if you are having a polyrepo setup and need to make changes in many places.
For bazaar style development where you accept contributions from anyone and don't use Github, the email flow is so much faster and simpler. Yes, you need to set it up once. But the other day I contributed to a open source project that was self-hosted, and it's amazing that I just can clone the repo, make my changes, commit and then git-send-email, bam done. Had I needed to sign up and create an account, set up a fork, I probably wouldn't have bothered because it was a small contribution. However no need to register to a website, no need to click through a slow ui, no need to create a fork, it reduces the ritual to make contributions by quite a lot, given that you've set it up.
I am glad that there is a good alternative that supports this flow, because I think it is superior. There are a ton of alternatives if you want the PR flow (Gitlab, Gitea, Github, Codeberg).
I’ve done the email workflow for a bit. I’ll say this much: it might be comparable to configuring a power editor vs. using some powerful and ready-to-go IDE. You can set up things how you like and the preferences of everyone else doesn’t really matter. You can also just edit anything because it’s fast and there is probably a good enough configuration for all kinds of languages and modes.
But in some ways it isn’t. Like any fool (like me) can just get some Emacs configuration for free from others. There doesn’t seem to be that kind of sharing for all the fiddly little things you need to do with git-send-email and the rest. All I’ve heard so far is that, oh yeah I usually deal with this specific issue by running some Perl scripts that I wrote eight years ago and that I’ve been nurturing ever since. But it wouldn’t be very useful for you because it’s very, very idiosyncratic. Might not even work outside Debian and my Apt state...
> But in some ways it isn’t. Like any fool (like me) can just get some Emacs configuration for free from others.
To be clear though: there are programs and tools beyond the git(1) tools themselves that help you with email workflows. Like b4 which is for the Linux workflow.
A few plugins to allow git-send-email to work without much configuration by using your existing Outlook or Gmail or Thunderbird setup (basically, a git plugin for outlook) would be very desirable.
That might be intractable. Some clients will rewrite/corrupt (whatever you want to call it) messages before sending. Like maybe it reflows paragraphs and ruins your inlined diff. Or it helpfully replaces tabs with spaces (the project requires tabs).
So what can you do with that? Doesn’t seem like you can do anything.
Outlook seems especially bad. [Here] is some HN hearsay about how even Microsoft had to run Linux machines in order to contribute to the Linux project.
If someone contended that SourceHut optimizes for devs who've been writing Linux kernel code for 25 years, so you weed out all the newbs and can get the hardened veterans involved in your project, I could buy that. I'd disagree that it's what I'd want for my project, but to each their own. I couldn't recommend it as an alternative to other services that require participants to know how to use a web browser.
[0]https://git-scm.com/docs/git-send-email