Not everyone has a fancy client-side MUA that gives them trivial access to mbox files. E.g., a typical webmail service will make exporting mboxes into a whole process at best. (And on the sending side, have fun with the lack of git send-email integration. I've spent far more time than I'd like manually patching up References and In-Reply-To headers.)
Of course, the classic response is "get a better MUA you luser", but that just adds even more steps for people who use webmail services for 99.9% of their email needs.
People can use webmail for regular email, but then connect a “better” MUA for patch handling. I get that this would be more steps, but for those who don’t want to do this, they probably just use GitHub PRs, and that’s fine, they can carry on doing that :-)
I’m just completing the picture by pointing out that for those who choose to use emails to jockey patches around by mutual agreement, including patches in emails really shouldn’t be a problem.
> Of course, the classic response is "get a better MUA you luser"
Git is distributed and allows you to work efficiently with poor connectivity, having full history available at any time, which is a big accessibility point for people with limited connectivity (and also helps people working while traveling, for example). If you do have any email client, you get all of this as well, plus arbitrarily powerful, low-latency filtering and searching. I recommend Greg KH's "Patches carved into stone tablets" talk [0].
Despite your "luser" strawman, people advocating for client-side MUAs mean well and have a point. Try replacing "webmail" by "Notepad" and "client-side MUA" by "emacs/vim" to see how your argument sounds. You probably spend a decent amount of time interacting with email, and the investment in setting up a fast, flexible and powerful environment (preferably reusing your text editor for composing messages) for doing so pays for itself soon.
> Try replacing "webmail" by "Notepad" and "client-side MUA" by "emacs/vim" to see how your argument sounds.
As it happens, I'm the kind of masochist who uses Sublime Text with no plugins for most of my programming (and literal Notepad for most of my note-taking on Windows), so I find value in letting people stick to their familiar workflow, even if some might see that workflow as somewhere between 'grossly inferior' and 'literally unusable'.
The nice thing with remote Git repos is that you don't need to care at all about how they work internally: you can speak to them using the same Git client (or GUI wrapper, alternative Git-compatible client, etc.) that you use for everything else. Of course, many people would prefer not to use Git at all, but it's a necessary evil to have some client if you want source control, and it doesn't take much work to set up. (At this point, I've installed several source-control tools that I don't really use nor have to worry about.)
But setting up an MUA solely for a git-send-email based workflow is several steps beyond that. E.g., some of the Linux maintainers demand inline patches, which physically cannot be done through many webmail services. So you're left with the slog of finding the right incantations for git-send-email (or an MUA you don't need for anything else) to provide the right credentials to an obscure SMTP proxy. And then you have to worry about how well-protected those credentials are, unless you have some sort of keyring or 2FA integration.
> You probably spend a decent amount of time interacting with email, and the investment in setting up a fast, flexible and powerful environment (preferably reusing your text editor for composing messages) for doing so pays for itself soon.
I'm a bit curious, how well do these tools handle HTML email? Webmail services come with WYSIWYG editors that I make liberal use of for formatted text. There's a big overlap between the "email patches are great!" and "HTML email is the worst!" crowds, but I'd be surprised if HTML email is totally anathema to today's MUAs.
> As it happens, I'm the kind of masochist who uses Sublime Text without any plugins for most of my programming, so I find value in letting people stick to their familiar workflow, even if some might see that workflow as somewhere between 'grossly inferior' and 'literally unusable'.
I definitely think there are upsides to not tweaking your text editor config endlessly, so I understand your point :) What I meant with "vim/emacs" is mostly that sometimes you really want to automate a text editing task, and then it's really convenient to have a programmable text editor. It's also very much a case of [0].
> I'm a bit curious, how well do these tools handle HTML email?
In my case, I use mu4e in emacs to read my mail. Very basic HTML works by default via emacs's native HTML renderer (see, e.g., [1] for old screenshots). That's my preferred solution because I like the keyboard consistency (it's just an emacs buffer) and because there is a command to view the email in an external browser if needed, but it is also possible to render HTML email accurately in emacs by embedding a webkit widget [2]. As for writing, you can write in Org mode format (emacs markdown, if you will) and it gets converted to HTML on send.
Of course, the classic response is "get a better MUA you luser", but that just adds even more steps for people who use webmail services for 99.9% of their email needs.