3 ms·

> I simply don't see how it requires significant expertise or a week to set up[...] I don't just mean the setup required to send a one-off patch. Obviously set

by avar 8y ago

> I simply don't see how it requires significant expertise or a week to set up[...] I don't just mean the setup required to send a one-off patch. Obviously setting up some random E-Mail client with IMAP is easy. But the sort of setup required to get anything like feature parity with common operations in GitHub's or GitLab's interface. E.g. when you open a Pull/Merge request on those sites. It's easy to apply & download the patch series locally to test it. For E-Mail client integration you need something that'll "git am" a range of messages. Likewise with "git push" to your topic branch updating the PR/MR. Sure you can do this all manually with git-format-patch and git-send-email, but having something that works smoothly takes a lot of work. And nowadays the network effects of that setup don't make sense for most contributors, because so few projects still use E-Mail like this. There's a large long tail of contributors to these projects, e.g. the median for patches in git.git per contributor is 2.

u801e 8y ago
> when you open a Pull/Merge request on those sites. It's easy to apply & download the patch series locally to test it. For E-Mail client integration you need something that'll "git am" a range of messages. That's a good point. Like git-am is the inverse of git-format-patch. Unfortunately, no program has been written as the corresponding inverse of git-send-email. If a program like that existed, then one could get feature parity. At least with Thunderbird, one can highlight the messages one wants to save and save them to multiple files in a folder. > Likewise with "git push" to your topic branch updating the PR/MR. Sure you can do this all manually with git-format-patch and git-send-email, but having something that works smoothly takes a lot of work. Based on what I've read, people typically rebase their patch series and push up a new set of emails as a reply to the original patch series. In Github/Gitlab, people typically make an incremental commit and push it up. But, if one wants to maintain a clean commit history for a given feature development branch before it's merged, one will have to rebase and apply those incremental commits to their corresponding base commit. That's trivial if the feature is implemented in a single commit, but a bit more complex if it's multiple commits. The former case has been addressed by Github with their squash before merge feature I believe. The latter case requires manual rebasing (which arguably is more more than just doing it locally before pushing up the next version of the patch set).
- xte 8y ago
  Hem, notmuch/mu4e offer easy magit integration so you can see, test, patch etc straight from a mail messages... That's the power of a text-centric UI vs a graphical-centric UI.
  - u801e 8y ago
    I'll try it out. vim is my main editor, so it will be a bit of a learning curve to get used to emacs :) As an aside, I have tried out gnus for reading the git mailing list via gmane, but I found it very slow in threading messages (when compared to Thunderbird). I don't know if notmuch/mu4e has the same issue though.

by avar 8y ago

u801e 8y ago

> when you open a Pull/Merge request on those sites. It's easy to apply & download the patch series locally to test it. For E-Mail client integration you need something that'll "git am" a range of messages. That's a good point. Like git-am is the inverse of git-format-patch. Unfortunately, no program has been written as the corresponding inverse of git-send-email. If a program like that existed, then one could get feature parity. At least with Thunderbird, one can highlight the messages one wants to save and save them to multiple files in a folder. > Likewise with "git push" to your topic branch updating the PR/MR. Sure you can do this all manually with git-format-patch and git-send-email, but having something that works smoothly takes a lot of work. Based on what I've read, people typically rebase their patch series and push up a new set of emails as a reply to the original patch series. In Github/Gitlab, people typically make an incremental commit and push it up. But, if one wants to maintain a clean commit history for a given feature development branch before it's merged, one will have to rebase and apply those incremental commits to their corresponding base commit. That's trivial if the feature is implemented in a single commit, but a bit more complex if it's multiple commits. The former case has been addressed by Github with their squash before merge feature I believe. The latter case requires manual rebasing (which arguably is more more than just doing it locally before pushing up the next version of the patch set).

xte 8y ago
Hem, notmuch/mu4e offer easy magit integration so you can see, test, patch etc straight from a mail messages... That's the power of a text-centric UI vs a graphical-centric UI.
- u801e 8y ago
  I'll try it out. vim is my main editor, so it will be a bit of a learning curve to get used to emacs :) As an aside, I have tried out gnus for reading the git mailing list via gmane, but I found it very slow in threading messages (when compared to Thunderbird). I don't know if notmuch/mu4e has the same issue though.