4 ms·

For me as a person who learned programming in the times of Github/lab/whatever, the idea of sending patches via email is fucking ridiculous. The typical interf

For me as a person who learned programming in the times of Github/lab/whatever, the idea of sending patches via email is fucking ridiculous. The typical interface for handling merge/pull requests adds so many useful things over just sending a patch - if the project has CI I can immediately see if it even successfully builds before even going into the details of the PR. Same for reviewing, each comment can be replied to separately or resolved, which serves as a nice TODO list for the original author. I know there are some things people don't like (I think Linus was pretty vocal about it), but it seems to be they could be easily fixed by modifying the available open-source forges. This proposal here for example fixes the concern about centralisation, so I guess it's a good step forward. Or maybe I'm just young and like shiny things and will eventually have a spiritual awakening and learn about the virtues of sending in patches via email.

madeofpalk 3y ago
The only way sending patches through email would actually work is if there was some interface on top of that process that managed that. By that point, it's probably easier to just use ActivityPub/HTTP as your protocol rather than SMTP/IMAP.
- xyzzy_plugh 3y ago
  Absolutely, but it's depressing that we have to build a whole new system instead of dovetailing with a system that not only works but is already universally deployed.
- taeric 3y ago
  I'm a little confused, there are interfaces on top of email based patch workflows? What do you mean?
JoshTriplett 3y ago
> For me as a person who learned programming in the times of Github/lab/whatever, the idea of sending patches via email is fucking ridiculous. For me as a person who learned programming before the Internet was a thing, and has worked both on projects that do patches by email and on projects that use web-based pull requests, I also prefer the web-based pull requests in every possible way. The email based workflow is baroque, painful both to send and to receive, lacking in features, and error-prone.
- LudwigNagasena 3y ago
  I would prefer `git request-pull etc` to actually make a pull request that anyone could see inside their editor, on GitHub, in their mailbox or wherever else they want.
  - JoshTriplett 3y ago
    Hopefully federated forges will make that easier, since it'll be easy for anyone to interface with using whatever technology they prefer.
- mariusor 3y ago
  I think we can all agree that the main reason why developers require distributed source control is in order to facilitate development in a parallel way. So, as a maintainer the purpose of such a request for collaboration (it being a PR or a patch) is to determine if: a) it does what it's expected out of it, b) it matches the conventions of the existing code. I, personally, can make a judgement about both of things better with a patch that I apply locally than with a PR. The main issue with PRs (in my opinion) is that they limit severely the context in which the changes are viewed. If I want to properly review a piece of code I have to check it out and follow the diff in its proper context (either while debugging) or even while just reading it. Source forges, through the PR mechanism, encourage superficial reviews and insufficient attention being given to the merged code.
  - madeofpalk 3y ago
    > I, personally, can make a judgement about both of things better with a patch that I apply locally than with a PR. How come? How is a text .patch file easier in this regard than a UI for essentially that same .patch? Can't you check out the PR in the same way you would 'apply' a patch to review it? For what it's worth, you can just add .patch onto the end of a github PR URL to get that.
    - mariusor 3y ago
      I don't look at the patch by itself, I hoped that was clear. I apply the patch locally, where I have the full context. I can of course do the same with the PR, but then it loses its convenience. :)
argulane 3y ago
This is the reason why a large part of the Linux kernel is actually developed in GitHub/GitLab. Just search for `github` in the maintainers file to see who many https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

madeofpalk 3y ago

The only way sending patches through email would actually work is if there was some interface on top of that process that managed that. By that point, it's probably easier to just use ActivityPub/HTTP as your protocol rather than SMTP/IMAP.

xyzzy_plugh 3y ago
Absolutely, but it's depressing that we have to build a whole new system instead of dovetailing with a system that not only works but is already universally deployed.
taeric 3y ago
I'm a little confused, there are interfaces on top of email based patch workflows? What do you mean?

JoshTriplett 3y ago

> For me as a person who learned programming in the times of Github/lab/whatever, the idea of sending patches via email is fucking ridiculous. For me as a person who learned programming before the Internet was a thing, and has worked both on projects that do patches by email and on projects that use web-based pull requests, I also prefer the web-based pull requests in every possible way. The email based workflow is baroque, painful both to send and to receive, lacking in features, and error-prone.

LudwigNagasena 3y ago
I would prefer `git request-pull etc` to actually make a pull request that anyone could see inside their editor, on GitHub, in their mailbox or wherever else they want.
- JoshTriplett 3y ago
  Hopefully federated forges will make that easier, since it'll be easy for anyone to interface with using whatever technology they prefer.
mariusor 3y ago
I think we can all agree that the main reason why developers require distributed source control is in order to facilitate development in a parallel way. So, as a maintainer the purpose of such a request for collaboration (it being a PR or a patch) is to determine if: a) it does what it's expected out of it, b) it matches the conventions of the existing code. I, personally, can make a judgement about both of things better with a patch that I apply locally than with a PR. The main issue with PRs (in my opinion) is that they limit severely the context in which the changes are viewed. If I want to properly review a piece of code I have to check it out and follow the diff in its proper context (either while debugging) or even while just reading it. Source forges, through the PR mechanism, encourage superficial reviews and insufficient attention being given to the merged code.
- madeofpalk 3y ago
  > I, personally, can make a judgement about both of things better with a patch that I apply locally than with a PR. How come? How is a text .patch file easier in this regard than a UI for essentially that same .patch? Can't you check out the PR in the same way you would 'apply' a patch to review it? For what it's worth, you can just add .patch onto the end of a github PR URL to get that.
  - mariusor 3y ago
    I don't look at the patch by itself, I hoped that was clear. I apply the patch locally, where I have the full context. I can of course do the same with the PR, but then it loses its convenience. :)

argulane 3y ago

This is the reason why a large part of the Linux kernel is actually developed in GitHub/GitLab. Just search for `github` in the maintainers file to see who many https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...