I shared this video on the Lobsters thread which seems to have been helpful for some:

https://yukari.sr.ht/aerc-intro.webm

Don't repost this, please, the official aerc announcement is coming in a few weeks.

I'm working on making a UI similar to GitHub's for reviewing patches which is built on email underneath, but can be used entirely on the web. The first step of this became available a few weeks ago, and now email threads are being rendered into a review UI which is similar to GitHub's with inline feedback and such:

https://lists.sr.ht/~philmd/qemu/patches/5556

This page is fairly new and still needs a bit more work towards mobile support, but I hope that gives you some more confidence in the platform. I intend to extend this so that you can also review patches from the web, which will generate emails on the mailing list, and prepare patchsets from the web as well. The end result will be a UI which is remarkably similar to GitHub in terms of usability on the web, but is backed up with distributed technologies and seamlessly integrates with the workflows of devs who would rather use email.

On the whole Sourcehut is actually quite a bit better at responsiveness than GitHub, too. Rather than a dedicated and inferior mobile site, almost all sr.ht pages are responsive and equally capable on all form-factors.

I love how sourcehut complements git rather than parasitizing on it. That is, I can't fault github's ability to be a dumb remote to publish branches to - but once you use it for that, they have a foot in the door for all the prongs of their proprietary lock-in and what is frankly value-subtract. I'm not worried about that with sourcehut because 1) I don't have to go full sourcehut kool-aid unless I want to (in fact, there's actually too little linkage among the components at present), and 2) if I do, then the kool-aid I've bought into is... a mailing list workflow using decades-old standard technology, where the webapp views are optional.

Friendly pedantry: in that video, you referred to vi as "vee"? :)

Yes, because that's what it's called :)

So you're saying that you don't care what the original author named his software, and you're going to say it your way, just to be different?

Whoa! This is a great idea. Looking forward to the "real" post; I've also done some work on implementing distributed systems over email, so I'll be sure to give this a look.

Looks awesome!

See "git format-patch" and "git am". The short name of "git am" is a hint that Linus probably used it a lot, given that git was built to replicate his personal idiosyncratic workflow.

(Obviously you have to use a command line mail client too, in keeping with git's spirit of user friendliness)

I have to say that format-patch and am workflow is really handy, even when working alone. (Say you want to test a commit on multiple dev machines but you're not sure if you're ready to push to a remote, as an example.) The flexibility to store or transmit a commit in patch form apart from .git or the remote, then seamlessly add it to the history, is a good thing.

> Obviously you have to use a command line mail client too

Not really. You could use a GUI client like Thunderbird to respond to emails pertaining to a particular commit as long as you're not actually trying to paste code in the composer. If you want to put something like a code snippet delimited by a "scissors line", then you'll need to use git format-patch and/or git send-email.

In other words, it doesn't matter what MUA (Mail User Agent) you use if you're just sending text, but if you are sending code in the form of a diff that someone will apply using git am, then you'll have to use a tool like git format-patch and git send-email to compose the message and send it.