|
Configuring git send-email is trivial, definitively faster than creating an account at some web UI from a "source forge" – it's literally setting a handful of properties in the `.gitconfig` – and those are not specific to a project, but just your mail server settings you can reuse them for any project that accept patches over mailing lists. And using it for a project that accepts this workflow is such a joy, no need to figure out weird merge request that make me re-enter all the information I had in my git commits already. If it's only a few patches, say three, I can do a simple `git send-email --to mailing@list.example.com -3`, maybe throw in `--cover-letter` for some meta info if the changes are even big enough to require that, and be done. Certainly to each their own workflow, and once can get accustomed to a lot of needless tasks and workflows, but how one can look at the bloated interfaces that try hard to add vendor-lock-in and say "this is so much simpler and easier to grasp" can IMO only mean they never tried this way in good faith.
In the end sending a mail is trivial, and code changes are text (most of the time), it can hardly be beat in simplicity. Anecdotally, most of our new hires from the last years had no experience with the email workflow, and a few weeks in most of them find it way better, while the rest finds it at least as good as the alternatives (and here they mean gitea or sourcehut, not the monsters that GitHub/Lab are). |
You forgot that mailing list requires subscription and in some cases it could be a tricky. Without proper subscriptions and confirming subscription, your mails with patches will go to trash.