These are the two most fundamental features of a PR. How could they decide so few as 10 is the right number of comments?
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.
[0] https://github.com/refined-github/refined-github
[1] https://github.com/refined-github/refined-github/issues/2151
Better to just find a dev-first platform instead.
I think the evidence is pretty clear that the most effective development process for large codebases is to look at changes as effectively a series of patches applied to head-of-trunk (and those patches may evolve during review)... and github seems to almost go out of its way to prevent you from thinking about PRs as if they were patches.
Those who take care to write meaningful per-commit descriptions are actively punished by the eager collapsing. Either reviewers have to (1) spot the ellipsis (2) click on it for each individual commit, or the submitter has to copy-paste all of their commit information into the PR description.
I'm trying to work on solving this and I have a first iteration of it which I wouldn't mind getting feedback on. If you look at the following PR:
https://oss.gitsense.com/insights/github?bt=open&q=microsoft...
you can easily identify which commit does what. For example, if you select the first two commits and filter by them, the PR tree will show you the files that were changed by those commits and if you click on the commit in the tree, you can view the diff for that commit.
In the future, I want to support what you described and make it very easy to diff any revision.
Unfortunately there are a massive number of codebases where a "simple" change can mean changing _lots_ of places.
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.
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...
Though relatively late, I am glad it's coming to Github, more people can benefit from this kind of pull request presentation.
https://www.atlassian.com/migration/assess/journey-to-cloud
There's still data center version but it's priced expensive to discourage you.
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 :)
Not sure how long it’s been in AzureDevOps but it could have been inspired from GitLab there I suppose.
Side-note: I took a look at the ‘About’ page thinking ‘Hey, they said ex-FB, extremely unlikely but maybe i know someone’. Looking at your username I’m guessing you’re jacob gold and worked on messaging infra in NY. I used to work on Iris! Small world.
Feel free to shoot me an email if you don't want to wait, although the list moves fairly quickly these days.
Also, I hate repos that convert issues to discussions. Might as well close the issue, as discussion is usually a graveyard.
'Moved to discussion' seems better to me than 'closed; tagged question'.
That’s why they do it, but what they’re doing is essentially rejecting the request. If it’s a question, sure, but if it’s a feature request or worse yet a bug report then moving to discussions is bs.
I don’t like scrolling until I see “holy cow wat”.
