1. 35
  1.  

  2. [Comment removed by author]

    1. 10

      I don’t think it’s just inertia. Having done a lot of email development, I can tell you, each line and commits gets a lot more attention than with Github PRs. The barrier to entry is (or was) very low: all a contributor or a reviewer needs is an email client (I realise “an email client” isn’t such a low barrier to entry anymore). It’s also about as flexible as plain text is: anything that can be done with text can be done while reviewing via email. You can comment, rewrite, forward, include others…

      With Github-style PRs, I’ve noticed people really tend to ignore individual commits and just look at the final diff. It makes it a lot harder for the contributor to individually explain smaller atomic changes with long-form commit messages, because people don’t look at the explanations. With email-based code review, each commit message is essentially a persuasive essay for why this one, small, atomic commit is a good thing.

      There are tools that try to bring email-like code review, such as Phabricator and Gerrit, but I’ve still felt them slightly constraining because if I want to do something slightly different than the way they do things (for example, comment in a different order than the one in which the patch was written), then the tool itself has to be modified. Email-based code review is based on the same low-tech idea that git itself is based on: a stupid and simple infrastructure that allows a lot of flexibility on top.

      edit: in case nobody is familiar with them, this is an example of the typical kind of commit messages that I think email-based code review promotes and alternatives do not. When I’m looking at a project’s history, these kind of long-form explanations are very helpful:

      https://lkml.org/lkml/2016/10/3/124

      And email is just text, it’s easy to integrate into stuff like Patchwork:

      https://patchwork.kernel.org/patch/9360367/