Show HN: A better way to review pull requests(github.com)
github.com
Show HN: A better way to review pull requests
https://github.com/colinjfw/prhero
4 comments
This is a very nice interface! I wonder how well it would scale for huge PRs (many thousands of line changes), which right now are both irritating to review on Github, and other tools like IntelliJ.
Somewhat related, but I wonder if some of the bottlenecks/constraints in this area are caused by the browser or electron (think GitKraken). I know that there are some new tools out there that differ, such as Sublime Merge which uses the same engine as Sublime Text, but I haven't had a chance to try that out yet.
It may be interesting to benchmark Gitlab, Github, prhero, Sublime Merge and other tools on PRs of various sizes..
Somewhat related, but I wonder if some of the bottlenecks/constraints in this area are caused by the browser or electron (think GitKraken). I know that there are some new tools out there that differ, such as Sublime Merge which uses the same engine as Sublime Text, but I haven't had a chance to try that out yet.
It may be interesting to benchmark Gitlab, Github, prhero, Sublime Merge and other tools on PRs of various sizes..
It should handle large PR's quite well. It probably doesn't right now but that's more a function of the code being hacky.
I think the problem with the GitHub UI is you have so much scrolling that it's a large amount for the browser to try and paint out and for a user to parse through. Since this is only showing a diff on a file at a time it's not subject to that issue.
I think the problem with the GitHub UI is you have so much scrolling that it's a large amount for the browser to try and paint out and for a user to parse through. Since this is only showing a diff on a file at a time it's not subject to that issue.
From my perspective, though, the largest annoyance of PR reviewing is that diffs are alphabetical instead of conceptual.
For example, a large change ends up affecting 26 files named A, B, ... Z. The PR diff/review lists the changes starting with A and the last changes reviewed are in Z. But, conceptually, often it'll be that - if you made the PR - you'd rather the reviewer start with Z: the high level, this is why the PR was even needed, then jump to F: the data structure change enabling this, then off to B: initialization code that needed to account for the structure changes, etc, etc.
Currently, the only way around this - that I know of - is with the comments section and just noting for whoever reviews it what to look at in what order.
Having a tool that fixed that problem would be heaven to me.