3 ms·

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 brie

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.

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

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.

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