Comment by da39a3ee | Hacker News Reader

Comment by da39a3ee | Hacker News Reader

Parent Full thread

No-one should be applying patches from emails. I know several people will react with certainty that I'm wrong, but email-patch-based flows are just used because the old-timers using them are very accustomed to it.

It makes vastly more sense to transmit a patch attached to the specific code base state that it is intended to modify: in other words a patch doesn't exist in isolation. Git is great; I'm not saying everyone should use any particular Git-hosting or code review framework. But the fact that the inventor of Git continues to use email in one particular project with many expert and experienced contributors has more to do with their expertise and experience (aka age) than with the benefits of email. I mean look at the reality of these people's workflows: they're using things like Mutt and Gnus to read email locally and apply patches from local email. I get it, I've done it, I've even run a local dovecot for the purpose. It had it's time in technological history. That time isn't now.

There are multiple open source projects that I would have contributed to were it not for the email-based flows (e.g. emacs).

I strongly disagree. I've recently contributed to a project that uses an email-based workflow, and find it considerably easier to use: after a surprisingly brief one-time setup, I can contribute patches using a single `git send-email` command from the same terminal that I make my commits, and can review and comment on patches from my email client of choice (thunderbird) – all without needing to create a new account.

Applying patches is, admittedly, a little more awkward, but it can still be done in two or three steps from thunderbird (including invoking `git am`) and, I understand, some newer email clients can handle this much much better.

> It makes vastly more sense to transmit a patch attached to the specific code base state that it is intended to modify:

This is no longer a problem. `git send-email` (and `git format-patch`, if you prefer to call it directly) has for a while supported a `--base=auto` or the `format.useAutoBase` configuration option to attach the upstream commit ID to the patch. To my knowledge this is currently only to help the maintainer understand its context but there is ongoing discussion of ways to automatically use this information.

How is that better than having shared access to a remote git repo and your collaborator sending you a commit sha and branch name?

Note that I'm not suggesting you use any for-profit company's hosted git product.

The biggest difference is the need to have shared access and it therefore does not easily allow for contributions from people without write access to the repo, although a similar workflow is possible with multiple publicly-readable repos (esp. with the help of `git request-pull`). Another advantage a send-email–based workflow has (compared to the workflow you describe, at least) is that the presence of the patch in the email makes it trivial to respond to specific code changes inline, using standard email quoting.

ETA: Many forges reintroduce the latter (commenting directly on lines of code), in which case this may not be an advantage depending on if such a forge is used. (But then you're back to using a forge, and needing to open the website to review changes in addition to using git and email.)

Perhaps I should have been more explicit: sending "a commit sha and branch name" is functionally equivalent in that it contains both the information necessary to retrieve the commits and a method of responding to the new commits, but is considerably less convenient. There is an extra step in sending the commit (you must push the commit then send the relevant data using a separate email client), and the resulting email lacks both the commit message explaining what was changed and why, and the changes in question, requiring one to manually examine the commits out-of-band. This is in addition to the need for all contributors to have write-access to the repository, mentioned above.

It is, however, also functionally equivalent to a pull request, excepting again the need for write-access.

> But then you're back to using a forge, and needing to open the website to review changes in addition to using git and email.

It sounds to me, and I mean this quite objectively, not as a personal insult, that you're attracted to the email-based flow not because it is better, but because you just don't want to use a web UI. So since you define web UI as bad, you of course reach the conclusion that the email-based flow is better.

I'm not sure I phrased that correctly. The point I was trying to get across with that sentence was not so much that web UIs are bad, but that if you are using a forge with in-browser support for reviewing changes (generally in the context of pull requests), then there is little benefit to sending "a commit sha and branch name" separately. Similarly, send-email–based workflows have little need to manage the repository in the browser. Email-based workflows and pull-request-based workflows are parallel in that they provide the same features in different ways.

We can quibble about which is more convenient (admittedly I find the former better in this regard, although I recognize that this is a minority opinion), but they are IMO both more-or-less equally viable choices.

Reply on news.ycombinator.com