5 ms·
Why do open source projects use emailed patches vs. published branches/PRs?
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've added some notes below which might help discussion but I know it'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)?
I'm distinguishing the following three states:
1. email: contributors email patches to a mailing list
2. published branches: contributors publish branches containing their commits, but there is no code review / commenting interface (a "pull request")
3. pull request: a published branch with a code review / commenting interface
Reasons for/against published branches over email:
- 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.
- Email may cause character encoding issues, published branches do not have this problem
- 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: "The branch names acts as a constant label, referencing a changeset which may evolve during development and review"
Reasons for/against PRs over published branches:
- Inline commenting makes code review very convenient. The PR records the review, the responses and the final sign-off / decision.
- But comment metadata belong to whoever owns the server hosting the PR and therefore may be lost
(Emacs has recently moved to git and I believe the maintainers would ideally like to use published branches / pull requests.)
- viraptor 10y ago> 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-5654674 https://github.com/torvalds/linux/pull/17#issuecomment-56546... (check out all Linus' comments, there's a few of them)
- Myrmornis 10y agoIf not character encoding, then issues with non-printing characters. See e.g. https://lists.gnu.org/archive/html/bug-gnu-emacs/2012-10/msg00339.html https://lists.gnu.org/archive/html/bug-gnu-emacs/2012-10/msg...
- viraptor 10y agoI 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 10y ago`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/w957vpu3PPU https://groups.google.com/forum/#!topic/linux.kernel/w957vpu... which indicates that apparently Linux kernel development uses the "published branch" workflow, in addition to (?) the "email patches" workflow.
- anarazel 10y agoSaw 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.