
Why do open source projects use emailed patches vs. published branches/PRs? - Myrmornis
On the face of it the persistence of emailed patch work flows (e.g linux kernel, postgres, emacs) seems archaic, inconvenient and error prone. I wanted to try to understand why projects do this and what it would take for it to become a thing of the past. I&#x27;ve added some notes below which might help discussion but I know it&#x27;s a fairly complex issue and the notes do not cover the issues. Can anyone provide any further insight into the situation and how we can get away from emailed patches (or disagree with that implied premise)?<p>I&#x27;m distinguishing the following three states:<p>1. email: contributors email patches to a mailing list<p>2. published branches: contributors publish branches containing their commits, but there is no code review &#x2F; commenting interface (a &quot;pull request&quot;)<p>3. pull request: a published branch with a code review &#x2F; commenting interface<p>Reasons for&#x2F;against published branches over email:<p>- Unmerged work might be lost, e.g. if a contributor publishes their proposed branch to a server hosted by a private company and both the contributor and the hosting company disappear.<p>- Email may cause character encoding issues, published branches do not have this problem<p>- The  branch name acts as a tag: the patch set may be appended to or rebased while retaining the same name. Sending successive emails with different patch versions creates a mess. EDIT: Reword as: &quot;The branch names acts as a constant label, referencing a changeset which may evolve during development and review&quot;<p>Reasons for&#x2F;against PRs over published branches:<p>- Inline commenting makes code review very convenient. The PR records the review, the responses and the final sign-off &#x2F; decision.<p>- But comment metadata belong to whoever owns the server hosting the PR and therefore may be lost<p>(Emacs has recently moved to git and I believe the maintainers would ideally like to use published branches &#x2F; pull requests.)
======
viraptor
> Email may cause character encoding issues, published branches do not have
> this problem

Not in this age anymore. This is pretty much solved after 2010.

> The branch name acts as a tag

This is a confusing statement, considering the tag is exactly something that
doesn't move.

> Sending successive emails with different patch versions creates a mess.

Usually there's an explicit patch versioning applied, like "PATCH v2"
([https://lkml.org/lkml/2016/8/27/76](https://lkml.org/lkml/2016/8/27/76))

This is the classic read on the topic:
[https://github.com/torvalds/linux/pull/17#issuecomment-56546...](https://github.com/torvalds/linux/pull/17#issuecomment-5654674)
(check out all Linus' comments, there's a few of them)

~~~
Myrmornis
If not character encoding, then issues with non-printing characters. See e.g.

[https://lists.gnu.org/archive/html/bug-gnu-
emacs/2012-10/msg...](https://lists.gnu.org/archive/html/bug-gnu-
emacs/2012-10/msg00339.html)

~~~
viraptor
I think there are two ways of using emails for exchanging patches that are
very different here. The first one is "just paste the patch as text" which you
can assume will cause issues. It's just a bad idea, because it depends on what
your email client is doing. (and things like outlook will change some symbols
into smileys and strip all your leading whitespace) The second one is - use
something like `git send-email`, which uses a common format, avoids this issue
completely, and can be directly imported back to your VCS.

Projects which use the mailing lists as the primary way to distribute patches
usually require the second way.

~~~
Myrmornis
`git send-email` may work well, but it's an extremely niche way to send email
and therefore it puts a huge barrier in the way of contributing to a project
for the first time: is my "From" address correct, have I got SMTP configured
correctly, etc etc. I just sent a patch to an open source project and attached
it as a file using Google's mail client because as you say pasting it an email
is a silly thing to do. But it ended up with some sort of non-text MIME
encoding and therefore wasn't visible in HTML mailing list web pages, and I
had to send a follow-up with it pasted into the email. So now there's a mess,
and which one is the point of truth? I just want to contribute a patch, I
don't want to think about low-level implementation details of email.

The discussion you link to seems to be mostly a rant against using the Gihub
UI to _create_ commits. What the overwhelming majority of good software
engineering teams do nowadays is create commits locally and then use some tool
to provide a review interface for a branch (e.g. Gitlab, Github or the stuff
used internally at bigger companies).

Incidentally Linus links to
[https://groups.google.com/forum/#!topic/linux.kernel/w957vpu...](https://groups.google.com/forum/#!topic/linux.kernel/w957vpu3PPU)
which indicates that apparently Linux kernel development uses the "published
branch" workflow, in addition to (?) the "email patches" workflow.

~~~
viraptor
> `git send-email` may work well, but it's an extremely niche way to send
> email

It is. You'd likely do it only if the project required it. And that's what
it's for.

> it puts a huge barrier in the way of contributing to a project

I guess it depends on a project. Would I tell anyone to configure git-send-
email for something simple? Probably not. Does anyone care about enforcing it
when developing an operating system? Probably not - the patch and testing
required way more experience anyway.

> which indicates that apparently Linux kernel development uses the "published
> branch" workflow

Yes, it does. Some subsystems maintainers keep their own trees that are merged
whole, rather than separate patches. But pretty much all dev contributions are
patch emails first.

------
anarazel
Saw this late. If you're still interested, I could give one (there's surely
multiple views on this) from the POV of a postgresql contributor and
committer.

