Email and Git = <3
I&#x27;ve used email-based workflow for a few contributions I&#x27;ve made.<p>The git-send-email part isn&#x27;t too bad. It&#x27;s everything else I have a problem with:<p>- You can&#x27;t subscribe to a single PR&#x2F;bug&#x2F;feature-request thread. Subscription to the mailing list is all-or-nothing. And no, setting up email filters is not a reasonable solution.<p>- 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&#x27;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.<p>- The flow for &quot;Dealing with feedback&quot; 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&#x27;ve had mixed success with it.<p>- Although I haven&#x27;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.<p>- Again, I haven&#x27;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 &quot;merge&quot;.<p>- 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&#x27;t handle long lines, so I had to resend it with the patch as an attachment.<p>- 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.<p>- etc.