[mariusor]

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]

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

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

[sdht0]

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

[JoshTriplett]

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

[avgcorrection]

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)

[JoshTriplett]

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

[ezst]

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

[avgcorrection]

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

[ezst]

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.

[mariusor]

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.

[ezst]

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

[mariusor]

Sourcehut can host mercurial repositories.