I appreciate the effort here, but after learning the workflow and having to get all this set up on a few computers, having to configure git send-mail is honestly just needlessly annoying and absurd.

Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors, but they also form a weirdly religious culture that fetishizes needlessly painful process and is incapable of improvement

I've used email-based workflow for a few contributions I've made.

The git-send-email part isn't too bad. It's everything else I have a problem with:

- You can't subscribe to a single PR/bug/feature-request thread. Subscription to the mailing list is all-or-nothing. And no, setting up email filters is not a reasonable solution.

- Email clients are pretty much universally terrible. Especially if you want to use the same client for your git flow as you do for regular email. Most clients don't handle inline-replies well, and require some extra work to send plain text emails. Clients that do work well for that often have a steep learning curve, and are missing features if you want to use it for general email.

- The flow for "Dealing with feedback" in this tutorial will start a new email thread instead of replying to the existing one. There is a way to reply to an existing thread with send-email, but it is kind of involved since you have to look up the message id of the email you are replying to (which may or may not be easy depending on your email client). And even then, I've had mixed success with it.

- Although I haven't been on the other side of it, it seems like reviewing the patch would be somewhat difficult without additional tooling. Especially comparing new versions dealing with feedback to the original version.

- Again, I haven't been on that side of it, but it seems like applying the changes from an email would be a bit of a pain compared to just pressing "merge".

- You can run into issues if your lines of code are more than 78 characters long. I used git-send-email to send in a patch once that had this, but the email client of the receiver couldn't handle long lines, so I had to resend it with the patch as an attachment.

- Some mailing lists require you to subscribe before you can send a patch. And if the list is pretty active, that can flood your inbox. See my first point.

- etc.

I love this. This is how it was done back in the days of usenet. People would email patches to the linux kernel. Hackers, working alone, late at night, strange times, strange places. Cultivating their work and skills and then ... shoot ... sending an email! Their contribution. So cool!

Maybe we should go back to this. Get rid of the whole github thing. Every group their own little mailing list. Laboring in private!

Not related to Git + git-email. I just want to say that I love the way this website is structured. Also, it renders fast.

> Warning! Some people think that they can get away with sending patches through some means other than git send-email, but you can't.

Could someone elaborate on this? Obviously it’s not intended, but is there anything wrong, from a technical standpoint, with using `git format-patch`, zipping the result, attaching it to an email using a GUI email client, and sending it to a maintainer who unzips and runs `git am`?

I appreciate the effort here, but in the proposed workflow are missed steps with subscribing to a mailing list. Without proper subscriptions and confirming subscription, your mails with patches will go to trash.

Email-driven contribution systems, no thanks. Why anyone would, in 2023, elect to use email as the backbone for their development processes eludes me.

I enjoy tutorials like this, in the same way and for the same reasons that I enjoy videos where people make cutting tools out of obsidian that they chip by hand.

Personally, though, when I have to actually cut something, I use stainless steel knives or scissors, which are cheap and readily available and do a much better job. Same with pull requests. But historical reenactment can be a fun pastime.

Personally, I enjoyed using Git with e-mail when Wine still used it. That said, the major improvement of moving to GitLab is that it's now easier to track changesets individually, as there is now a single place to look for a given changeset, rather than having to follow chains of e-mails.

And that having been said, I really GitHub/GitLab/etc. could move on from the pull request model and into a more change-oriented model like Gerrit or Phabricator. These are clearly better models in my opinion, and for most uses it's not even dramatically different.

I wish I could "preview" sending my patch to mailing lists. I've considered the idea of having a localhost mailing list for the sole purpose of sending it there just to make sure that i've got everything setup right, but haven't gotten around to doing it yet.

Just dropping this gem of a talk[1], for the uninitiated. There is a place for this, even if people in the thread have never seen it.

[1]: https://www.youtube.com/watch?v=vyenmLqJQjs

Amending commits, while having the advantage of keeping the git tree pristine at every single point, is incredibly uncomfortable for async workflows such as the one suggested, where your review might take hours/days and you want to continue coding in a forked branch. Upstreaming any code review changes becomes a pain as git treats the two branches as completely distinct.

Shown to HN on April 2019: https://news.ycombinator.com/item?id=19574257

Is there any collaboration tool (reviews, etc.) that uses git itself to sync the status? Adding email or whatever seems unnecessary, and github et al. seem contrary to the spirit of git.

off topic, but why does the page (step 2) rant about protonmail?

Can somebody elaborate?

>Be advised that Protonmail is generally known to be a pretty bad email host. [...] Not to mention their mistreatment of open source and false promises of security! You should consider a different mail provider.

The world has moved on. Products like Github and Gitlab supercharge these capabilities so far beyond what the Linux Core team are doing with their email lists.

Oh, I thought this was like a PR notification system, it's to actually send the diff to an email list. And the recipients would pull in those changes from the email? I think that's kind of how things worked a long time ago IIRC. Is the goal that this would be as official as how we push to remote, then file a PR now?

Actually, if you want to cut out all the systems like github or git lab, why wouldn't the team just set up a VPS with standard ssh access and that would be the main repo people push to since git supports many protocols like ssh, and even file:// (which I use for my local projects which are backed up).

It's easy for the VPS admin to add new team members, just a standard Linux account. It might be possible to even set up a restricted account so the member ssh'ing in a commit using git only has access to the repo and can't get a login shell.

One thing this is missing is cover letters for longer series. Last time I checked that was the biggest pain: the fact that there's no real convenient way to store the cover letters; `git send-email --cover` will expect you to compose a new one every time.

This is the fediverse they want

Please do not contribute to this silly archaic practice. It was once not silly. It is now archaic, and it is silly to do it now that we have vastly superior tools.

Weird way to list and sort OSs there.

Microsoft Windows but last, due to the W I guess but macOS has no Apple in it.

Too bad google has disabled "insecure apps" meaning I have a couple of ffmpeg patches sitting around because I haven't yet migrated it to my own domain. I thinking of sending from "FuckYouGoogle".

Seems like you're sending plain text emails, no? I have links for websites, resume etc. in the signature so I am not sure how this is conducive to that. Unless there is a method to add a signature with links?

Why not use a branch? This was the only surprisingly part to me. Won't this get messy when I try to pull the code later on? I don't know how the maintainer is going to merge my patch.

This is so absurd. The complexity of this setup is off the charts. If you thought memorizing terrible inconsistent git commands was bad enough, this just cranks it to 11

Not really a huge fan of this whole method, but the GitHub CLI is really well thought out and means I basically never need to leave the terminal if I don't want to.

It is way faster and easier for me to just open up my email client, attach a patch, and send it.