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