Hacker News Reader

Comment by alufers | Hacker News Reader

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.

View on HN

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

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.

Hopefully federated forges will make that easier, since it'll be easy for anyone to interface with using whatever technology they prefer.

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.

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

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

> I can of course do the same with the PR, but then it loses its convenience. :)

Not at all. A PR still retains all the other useful features like separate threads for comments which be individually marked as done and CI checks. And not all PRs need a local checkout for a review.

> I, personally, can make a judgement about both of things better with a patch that I apply locally than with a PR.

FWIW, my git is configured in such a way that pulling from github also pulls all PRs for that repo, so, in effect, all PRs are applied locally, and I can review them however I want.

I do think that email threads (when all parties are disciplined and have them properly configured) are superior to the PR+comments format for discussion, but applying patches from a mailbox has never seemed to me like a pretty and reliable way to go, so at least github helps with that.

At any rate, git sucks for reviews in general because it still lacks mercurial's "mutable-history"/evolve approach to safe and distributed history rewriting (or "diffs of diffs"), and that, to me, is saddening as one more evidence that git's monopoly is causing stagnation and unnecessary pain in this space.

As I replied to a sibling comment. I agree that I can review PRs on my local machine, which is sometimes what I do, but that means that the upside of viewing them directly on the source forge is lost, and I might as well have received a patch. :)

> is saddening as one more evidence that git's monopoly is causing stagnation and unnecessary pain in this space.

I disagree strongly with this type of sentiment. Mercurial works, mercurial source forges exist. It's entirely possible to use them for development. Complaining about git's success despite that feels a bit disingenuous.

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

> but that means that the upside of viewing them directly on the source forge is lost, and I might as well have received a patch. :)

I don't follow, github gives it to you both ways, so I don't see the downside here. And on top of that, you can pull comments into your IDE of choice would you need to. I hardly see the problem, I suspect it isn't technical.

> I disagree strongly with this type of sentiment. Mercurial works, mercurial source forges exist.

Your disagreement doesn't align with the reality, unfortunately. Could you name one mercurial forge? They aren't many left anymore, and you have to get out of your way to host your mercurial code somewhere. And while it's hard to name mercurial forge, it's easy to name high profile projects which reluctantly converted to git: python, mozilla, pypy. It only got worse over time, "interestingly", about as fast as git consolidated its monopoly. And that's the main flaw in your point, that success somehow is based on merit alone, with no influence of peer/social pressure/network effect.

FYI, I just submitted this post: https://news.ycombinator.com/item?id=39208464 which is pretty much what remains of hosted mercurial today.

Sourcehut can host mercurial repositories.

You can still get a “diff of diffs” with git range-diff. (If I interpret you correctly.) Like it says that in this iteration a paragraph was added to one commit, another commit was dropped, and another commit was expanded.

But you gotta do most of the work of lining up what the previous thing was yourself. (Inconvenient if you rebased and can’t seem to find the previous version.)

Mercurial's evolve is more about tracking history rewrites and their context. If I submit a series of commits, and over the review you have me amend one mid-series, then rebase few identically on top of that, then add some new changes, and split some existing ones, mercurial will still know how every single commit in the resulting series relates to things from the original PR. As such, answering questions like "show me how commit 3 was updated several times over multiple series submissions" is trivial.

> I, personally, can make a judgement about both of things better with a patch that I apply locally than with a PR.

`gh pr checkout NNN` works very well to give a local copy for review, by pulling and checking out the PR branch. There are equivalent commands for gitlab.

Also:

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

Both PRs and emailed patches encourage reading and reviewing just the patch. With emailed patches, you need to prepare a local branch with the patches applied if you want to do the kind of review you describe; with a PR, you need to fetch and checkout the PR branch. I would argue that checking out the latter is substantially easier than the former, especially given the availability of command-line tools like `gh pr checkout`.

Others keep in mind that Josh is so experienced with the email workflow that he made a tool to manage multiple versions of a “patch series”: git-series

(git(1) doesn’t help you with maintaining patch series)

Thank you, you just made my day. (I feel bad about leaving that undermaintained, though.)

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.

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.

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

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

Reply on news.ycombinator.com