3 ms·

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,

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.)

da39a3ee 3y ago
> 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.
- Sprocklem 3y ago
  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.
Sprocklem 3y ago
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.

da39a3ee 3y ago

> 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.

Sprocklem 3y ago
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.

Sprocklem 3y ago

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.