I’d settle for them making PRs as useful as they were in 2015, before they messed up some of the most basic functionality: showing the diff, and showing review comments. They hide big diffs behind a “load more” link, and as a result people often fail to code review the most substantial part of a change because they scan right past it, thinking it’s a removed file or binary or something. Then, once you submit a review, they only show 10 comments. In the middle, there’s an easy-to-miss “load more comments” button.<p>These are the two most fundamental features of a PR. How could they decide so few as 10 is the right number of comments?
Not sure if this is well known, but press period `.` when viewing a PR, repo, or file and github will send you to a in-browser visual code editor. Able to make commits in there too, perfect for [nit] comments
Bitbucket Server and Gitlab have this feature and it's quite useful for very large pull requests as you can easily see the folder structure of the file you're reviewing, for that bit extra bit of visual context. Bitbucket's search box is slightly better because it also does a code search within the PR, it helps you quickly find specific words (say, a class name) across all the changed files. Gitlab's only does a file name filter.<p>Though relatively late, I am glad it's coming to Github, more people can benefit from this kind of pull request presentation.
Funny but Azure Repos actually has had this feature for a while. When I first joined Microsoft I was shocked that all our teams used Azure Repos instead of GitHub considering we own GitHub but as I've used Repos more and more I've actually come to like it more than GitHub itself. A lot of the UI is cleaner and more intuitive than GitHub to me now, maybe just from using it a lot.
Hi! I am one of the authors of <a href="https://graphite.dev" rel="nofollow">https://graphite.dev</a>, we are basically a really fancy client to GH that lets you review others PRs without making them change their workflow at all (posts everything to GH etc)<p>We've had a file tree for some time now (along with some of the other feedback I'm seeing in this thread, large diffs etc).<p>If anyone wants to give it a spin, happy to give you an invite :)
If anyone is interested, I've been building a code review tool called Crocodile[0] that lets you review GitHub PRs. It has a similar file browser to the left plus floating comments, threaded discussions, and more.<p>[0] <a href="https://www.crocodile.dev/" rel="nofollow">https://www.crocodile.dev/</a>
Back in the day I created something similar for CLI, which lets you diff any change in tree format.<p><a href="https://github.com/oguzbilgic/tiri" rel="nofollow">https://github.com/oguzbilgic/tiri</a>
I'm currently using Octotree[1]. It has more features than this proposed GitHub implementation. Namely, files have icons, count of added/removed lines is displayed inline, comments are displayed inline (super easy to jump from comment to comment), etc. For now I'll keep using Octotree but I'm curious of the direction this implementation will take.<p>[1] <a href="https://www.octotree.io/" rel="nofollow">https://www.octotree.io/</a>
If you don't want just a tree but also a semantic diff that tells you what types and methods where actually changed check out Reviewpad (<a href="http://reviewpad.com" rel="nofollow">http://reviewpad.com</a>).
After many years at Facebook I’ve recently switched jobs and have to use GitHub now for work. Compared to Phabricator (FB’s code review tool), the GitHub code review (and code merge) processes seems extremely basic and clunky.
What's ironic is that discussion pages, like the one linked here, are broken on mobile. Maybe they should focus on that first.<p>Also, I hate repos that convert issues to discussions. Might as well close the issue, as discussion is usually a graveyard.
Display performance switching between files in Safari is terrible on very large PRs. I don't know what it could be doing. Maybe something to do with text reflow? But it's almost unusable.