
Show HN: A better way to review pull requests - kodebrew
https://github.com/colinjfw/prhero
======
massung
Interface looks nice!

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.

~~~
kodebrew
Huh interesting. I do agree that this is also a problem for me.

Would it follow naturally from just being able to see the files that are
affected? I'll look at the model file first and then move onto the controller
file for example.

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

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

