I'd love to know why I have been downvoted on that...

the answer is in one of the first lines in your linked article "Email isn’t as sexy as GitHub"

You know, I never really tried that. But I will do so when the opportunity arrives!

It is really easier than it looks! Took me a while to try it, but then I realized it's really super easy: run the git command to create the e-mail, send the e-mail, and on the reviewer side just run the command to apply it.

This is a nice tutorial, too, but I would recommend reading Drew Devault's posts first (and watching his short videos):

https://git-send-email.io/

Don't you lose a bit of important information when you create a patch? Like which commit it started from.

You don't send a diff, you send an e-mail formatted by git. So you get all the commits you put in it, it's really just like seeing the commits in a GitHub PR.

So the reviewer receives the commits, with their descriptions, authors, everything. Just like pulling a branch, really.

You do lose the information about where to apply the patch. This isn't a big problem for rebase-friendly crowd. But people who prefer the merge strategy strictly may not like it.

AFAICS there's `--base=auto` which captures explicit parent's sha in the patch text output (there's also a git config option to do that automatically).

Source: https://git-scm.com/docs/git-format-patch#_base_tree_informa...

Thank you for the information! This is the first time I'm hearing about it. Would you happen to know how this information is used? Is it just for the maintainer, or is there a tool that can use it? (I couldn't find any other reference)

Last time I checked it was only for maintainers convenience but the idea of using it by some tooling was already being discussed: https://people.kernel.org/monsieuricon/all-patches-must-incl...

I have been giving this one a lot of thought. I jumped to sourcehut for my personal projects and was amazed how viscerally pleasing a [PATCH] email thread could be. I am convinced there is a big psychological difference between discussions via Pull Requests and discussions via email/mailing lists. I can’t pin point it but it is almost palpable.

A question I have with the process is: can email based workflow still work with for a continuous integration/delivery pipeline?

> A question I have with the process is: can email based workflow still work with for a continuous integration/delivery pipeline?

Doesn't sourcehut already support that? (https://man.sr.ht/builds.sr.ht/)

> I jumped to sourcehut for my personal projects

Same :-). I also love how people don't have to create an account to send a patch. They just need to send me an e-mail. That is not a problem on GitHub (because everybody is forced to have an account there), but it is if you want to host your repo somewhere else.

> can email based workflow still work with for a continuous integration/delivery pipeline?

SourceHut has a CI feature integrated with the mailing-lists: https://man.sr.ht/builds.sr.ht/

The biggest drawback is the inability to use on a computer without email setup, e.g. not from the main computer, or from mobile devices - smartphone, tablet. In my case it's not uncommon to do a quick review of some PRs using this Web-based workflow. Now with newer GitHub application it's even easier.

I am not sure I follow this. If you can login to GitHub from your device, why couldn't you log into your e-mail?

The email-based workflow often requires quite specific email setup, many mobile-friendly email apps would break the formatting, etc, like Gmail.

It always amazes me that these large companies insist on reinventing the wheel.

Because their wheel comes with lock-in :-)