top | item 39201937

(no title)

alufers | 2 years 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.

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.

discuss

order

JoshTriplett|2 years 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.

mariusor|2 years 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.

LudwigNagasena|2 years 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.

madeofpalk|2 years 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.

taeric|2 years ago

I'm a little confused, there are interfaces on top of email based patch workflows? What do you mean?

xyzzy_plugh|2 years 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.