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.
These are the two most fundamental features of a PR. How could they decide so few as 10 is the right number of 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.
This. Every PR I have to do ctrl-F "load diff" and then immediately click on _all_ of the diffs. It's !@#$ing annoying.
I've also lost comments when the comment is part of a review and pushed to the PR after the the PR has been merged by someone else.
Maybe they're trying to nudge us towards smaller PRs. Many reviewers gloss over 300+ line changes in a single file. Approved with a "LGTM" and no further comment, but perhaps that's more a cultural issue with the team than anything.
Additionally, the notification email links to "View it on GitHub" don't reliably cause the relevant parts of the page to expand so you end up wading through a huge PR expanding things at random until you find the message.
This is by far the most infuriating thing about the PR UI, along with the fact that you can't comment anywhere outside of the "patch", meaning you can't point out anything that is more than a couple of lines away.
It's still not as bad as BitBucket which makes it basically impossible to read commit messages in a pull request. Is that a good level to be at? Probably not.
In the screenshot in the post it looks like the navigation tree is crammed into the 1280px wide grid, but that's not the case - enabling the feature preview makes the page full-width. So it doesn't make the diff area unreadable.
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
if you press it from a PR you'll get the vscode PR viewer which is way nicer than Github's (IMO, especially for larger PRs) the only thing missing is the ability to switch between changes from last commit, last review, etc.
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.
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.
Agree, I really prefer DevOps' PR experience. I'm just missing the easy GitHub ci Integrations (3rd party checks & bots that post comments for example). It probably also exists for DevOps, but I never came across of it
+1. I had the same experience joining Microsoft. I wasn't super thrilled by Azure at first, but was surprised by how much functionality it had. Fast forward a couple years later, I moved to another big tech company using Github instead, which had setup integrations with a bunch of different external tools (and this one was no slouch when it comes to engineering tooling). I can't tell you how much I missed Azure, even though I've had my issues with MSFT.
Azure DevOps is a very solid product in general. That said, the whole work items UI is terrible and inferior to the GitHub issue’s system. Too complex.
Hi! I am one of the authors of https://graphite.dev, 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)
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).
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.
Just casually following this thread, this is the third SaaS I've seen offering an alternative code review tool to supplement GitHub. It's either sorely needed to make up for how bad GitHub is, or it's true that we engineers can't help but makes tools for people exactly like ourselves.
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.
Since GitHub is owned by Microsoft and their other product has had this, I’m guessing it’s yet another copy-over like GitHub Actions was from Azure Pipelines.
Not sure how long it’s been in AzureDevOps but it could have been inspired from GitLab there I suppose.
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 (http://reviewpad.com).
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.
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.
eloisius|4 years ago
These are the two most fundamental features of a PR. How could they decide so few as 10 is the right number of comments?
inetknght|4 years ago
This. Every PR I have to do ctrl-F "load diff" and then immediately click on _all_ of the diffs. It's !@#$ing annoying.
I've also lost comments when the comment is part of a review and pushed to the PR after the the PR has been merged by someone else.
andrewf|4 years ago
88913527|4 years ago
thombles|4 years ago
lachenmayer|4 years ago
humanwhosits|4 years ago
formerly_proven|4 years ago
In the screenshot in the post it looks like the navigation tree is crammed into the 1280px wide grid, but that's not the case - enabling the feature preview makes the page full-width. So it doesn't make the diff area unreadable.
codeapprove|4 years ago
[deleted]
ydnaclementine|4 years ago
88913527|4 years ago
gfody|4 years ago
guessmyname|4 years ago
Link for people who didn’t know about this feature: https://mobile.twitter.com/github/status/1425505817827151872 and the official documentation with other keyboard shortcuts: https://docs.github.com/en/get-started/using-github/keyboard...
politelemon|4 years ago
Though relatively late, I am glad it's coming to Github, more people can benefit from this kind of pull request presentation.
wdb|4 years ago
mrrsm|4 years ago
OliverGilan|4 years ago
carstenhag|4 years ago
oneepic|4 years ago
voidfunc|4 years ago
tomasreimers|4 years ago
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).
If anyone wants to give it a spin, happy to give you an invite :)
brainbag|4 years ago
jameslao|4 years ago
[0] https://www.crocodile.dev/
eloisius|4 years ago
obilgic|4 years ago
https://github.com/oguzbilgic/tiri
noname120|4 years ago
[1] https://www.octotree.io/
dandigangi|4 years ago
alkonaut|4 years ago
Not sure how long it’s been in AzureDevOps but it could have been inspired from GitLab there I suppose.
marceloabsousa|4 years ago
radicality|4 years ago
jameslao|4 years ago
https://www.crocodile.dev
jacobegold|4 years ago
https://graphite.dev/
svnpenn|4 years ago
Also, I hate repos that convert issues to discussions. Might as well close the issue, as discussion is usually a graveyard.
OJFord|4 years ago
'Moved to discussion' seems better to me than 'closed; tagged question'.
BugsJustFindMe|4 years ago
croddin|4 years ago
other_herbert|4 years ago
eat_veggies|4 years ago
lh15|4 years ago
duxup|4 years ago
I don’t like scrolling until I see “holy cow wat”.
williamscales|4 years ago
codeapprove|4 years ago
[deleted]