Improved pull request "Files Changed" experience feedback #163932
Replies: 3323 comments 1384 replies
|
I would like to be able to scroll through the Pull Request while the comment modal is open. Reason: When a comment is outdated, we need to look at the current version to check if it actually addresses the comment. I really love this feature! THANK YOU!!! |
This comment was marked as low quality.
This comment was marked as low quality.
|
❤️ |
This comment was marked as spam.
This comment was marked as spam.
|
The button to "go to where this comment is" is a no-op. |
|
Came to ask this as well. There is a panel for comments, but when you click to go to the relevant line, it shows the previous section, not the new section. Thus, it's not easy to see if the requested change was actually applied. |
|
Update: I just found out that it appears when there's enough space (1280px width). Here's the updated feedback. I'd like to see the branch name in the sticky header at all times so that I can easily copy it when I'm reviewing a PR. I wrote the following before thoroughly experimenting. I'd like to see the branch name when the sticky header is shown (i.e., when you've scrolled to the bottom). The reason is that when I'm reviewing a long PR and want to checkout the branch to continue reviewing it locally, I have to go back all the way up to see or copy the branch name and then go back to where I left off. |
|
I know exactly what you mean — the old sticky bar made it so much quicker to jump back to the Conversation tab. Right now the extra scrolling or focus-shifting adds friction, especially during long reviews. A persistent header or sticky navigation with the tabs always visible would be a nice quality-of-life improvement. Not critical, but definitely one of those small things that would make the workflow feel smoother. |
|
This update focuses on three essential pillars of a modern code review experience: performance, UX, and accessibility. Optimized diff rendering with reduced memory consumption. |
|
This update focuses on three essential pillars of a modern code review experience: We’ve optimized diff rendering to significantly reduce memory consumption, |
|
Default auto goto V2344 |
This comment was marked as spam.
This comment was marked as spam.
|
I find the comment indicators in the sidebar really useful. It might also be useful to have them in the "diff file header." It's very useful when you've marked a file as "viewed" because you can see how many comments it has as you're scrolling without having to expand it. |
|
this is happening for me too. Some comments are showing up in file and some are not |
|
where is the copilot here? |
This comment was marked as low quality.
This comment was marked as low quality.
|
Hi @mohamedmagdysayed2040-prog, thanks for participating! Unfortunately, we don’t currently have moderators for languages other than English. Until that changes, we need to ask that everyone use English here in the GitHub Community when posting to ensure discussions are adhering to our Code of Conduct. We’ll be locking this post for now, but please feel encouraged to create a new discussion in English if you still need support. |
This is really cool. Is it also possible to seamlessly toggle hiding white spaces? If that's achievable without doing a refresh would be amazing. |
|
remembering per-user and per-PR seems both obvious and would result in a significantly better experience. |
"Hide whitespace-only changes" as a user-pref sounds good. |
|
Peer review comments are now very hard to find and finally after an hour of searching around I found the 💬 icon and when I clicked on the reply, it just barfed and took me to the |
This comment was marked as low quality.
This comment was marked as low quality.
I don't suppose you have any update on this yet, do you? It's really tedious to have to remember to:
Every Single Time I open a PR. Call me crazy, but it seems like there are an extremely small number of cases where one might not want this feature enabled by default. The mechanics of the feature itself seem so trivial, I'm sure Copilot could crank it out in 5 minutes. I hope to see some traction on this soon! |
|
Clicking a line number always assumes you want to add a comment. In the previous experience it only changes the URL to have deep linking. |
|
Any workarounds to obtain permanent urls? |
|
@rtalexk which browser are you using? Clicking the line number should just highlight the line, not open the add comment flow. |
|
I'm using Arc Browser, but this isn't happening anymore. 👀 |
|
It seems the comment urls are not working on the new experience if the PR is really big. The old UI still navigates to the comment correctly. |
|
This is so much better, I might go back from reviewing with the VSCode extension now 🚀 I love the new alerts panel, unfortunately it looks like pressing Maybe we could have some grouping or clustering in the alerts panel in the future. |
When this feature comes back, it'd be nice if hiding the annotations also stopped them from being added to the clipboard when copying code. |
|
Thanks for the feedback. We are planning to restore the ability to use |
|
@willsmythe any update on when this is getting added? |
|
In addition to using |
|
Are you not planning on adding this feature back anymore? Did you forget about it? Do you need help? If you need the code here is what I was able to do to add this feature from my browser console: |
|
I would love to see the file tree sorted alphabetically with folders on top, then files. It is quite jarring to have changed files in the middle of folders when viewing the file tree currently. Example of current state Example of desired state This would mirror how the majority of developers view the code in their IDE |
|
Indeed, files below would also be consistent with GitHub's own repo tree view. |
|
I see the value in being consistent with the repo’s tree view; nevertheless, having files listed first can have some interesting use cases. For example, if a PR includes a changelog file or a “manifest,” listing files first would make it one of the first (often the very first) files shown, which I think is nice when reviewing code. In my opinion, that would greatly help the review process. Just my two cents. |
|
I recommend sorting the same way as Old view: New view: |
|
Most tools put the folders first but I wish the standard was files first. The files in a folder typically describe its contents. For example READMEs, Changelogs, manifests, public functions/interfaces. The sub folders contain the implementation details. I would like to read those first when reviewing a PR (or writing code). That lets me see if their description makes sense to someone who does not know the internal implementation details. Then I can drill into the sub folders that contain the described implementation to see if they match. It also helps for languages, like golang, that have a |
|
I don't see the option to comment on the file itself, only on specific lines. Some files just get stuck into a loading state, like this one: The comments tab is really nice, I like being able to filter comments by author, makes it much easier to navigate the reviews and attend to the requested changes or overall feedback. |
App.tsxcomponents/ |
|
Should there be a separate thread for the "loading state" issue? I'm afraid this might be buried because the "comment on file" issue has been fixed. |
|
This is still happening for me when selecting "Files owned by me". They don't load, and I am unable to review. Any known workaround? |
|
Workaround I've just found, go back to old experience, then load again the new experience. |
|
|
Hi, I would like to play around with this, but I'm not seeing the opt-in mentioned in
Am I missing something? |
|
We are rolling this out to users slowly, you should be able to see it soon 🎉 |
|
The tab for |
|
I'd prefer that this button stay since it's related to the PR and its changes. |
|
Feature request: allow people who object to AI (and there are many of us) to turn it off, completely, without the risk of accidentally using it by some misclick or dark pattern. |
|
Bug: This button is visible even if Copilot is fully disabled in user settings. |
|
Asking Copilot to summarize the PR is important to my workflow, so I would like the Ask Copilot button to return to the Files Changed page as well. An alternative could be allowing non-main branch files to be attached to regular Copilot chat, since currently only files on the main branch for all repos can be attached. |
|
Because my team is understaffed, I often have to review PRs that use languages, frameworks, or libraries I am not very familiar with. With the current "Files Changed" view, I can use "Ask Copilot about this file-diff" right away, but in the new view it takes 3 clicks. For me, the version where I can use "Ask Copilot about this file-diff" with a single click is clearly better. |
|
Not sure if this is the sort of feedback you're after, but the |
|
Thanks for the feedback. We'll address. |
|
On the topic of emojis, I really liked that I could type e.g. |
|
This is urgent. You cannot link an issue to pull request within UI. |
|
The header got a max width in files changes view. It didn't use to and it looks weird now! |
|
It would be really useful to be able to filter changed files with a filepath glob or similar. I often have PRs that have a very large amount of changes which overwhelm the reviewing UI, but where most of those changes are mechanical changes to test fixtures which I either don't need to review or want to review separately. If I could exclude |
|
+1 to this. Another scenario is filtering out NuGet lock files. On very large solutions, a new project reference could result in hundreds of |
|
I found this bug: |
|
Please put the lines/amount changed diff back in a similar, visible place! |
|
Awesome feature guys, well done. The scrolling is broken on the files-changed tab. In a PR with 30 files around 1k lines of changes, from the top of the page touching the scroll wheel instantly jumps to some random location about half way down or further. The location is different every time. If I scroll all the way back to the top and then touch the scroll wheel again to scroll down even a tiny bit, it instantly jumps to a new location. This is on Safari on macOS 27.0.1. |
|
Had an instance today where after making a change to address a comment (inline), rather than the comment no longer appearing in the diff view, and being shown with an "Outdated" label in the overview tab, it was still present in the diff, seemingly attached to the specific line number. |
|
I'm still getting a feel for this and have noticed several issues with auto open on half sized screens for the stacked check/comment/approval banner, and this feels like so much wasted space to me. |
|
The PR # moveing to the top left corner so tiny is really difficult to see/find |
|
Me no like this gap |
|
Keyboard shortcuts change: The previous comment box allowed control+enter/command+enter for submit, and the new one only allows alt-enter/option-enter. Pure muscle-memory issue, nothing wrong with alt-enter, but ctrl-enter feels more common to me, so it's going to trip me now and again. |
|
Where is the fils filter? Sometimes i get thousand line prs where there majority of the diff is just translation |
|
On a wide screen I often see weird alignment of the header in diff view, like this |
|
Nearly two inches of headers at the top of the page waste a lot of space |
|
The context menu in the top left hand corner changes depending on how far you've scrolled down. Don't scroll at all, or scroll a little and it is a generic github menu Scroll more and now it's a PR context menu. The end result of the shifting menu is that the user can't trust what the menu is expected to do without pausing to think whether they have scrolled enough to cause the menu to shift meaning. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
About the new experience
This updated experience focuses on performance, accessibility, and user productivity. Read more in the changelog.
Tip
If you are not already using the new experience, click the ✨Try the new experience in the upper-right corner of the classic "Files changed" page. You can easily switch back from the Preview menu.
✨ What's new
If you are coming from the classic experience, the new experience should feel familiar but adds some significant improvements:
✨ Updates
See what's been fixed and improved since the launch of the public preview:
🟡 Limitations
As of the initial public preview release, there are some temporary limitations that will be addressed over time:
While our previous experience had hard limits on large PRs, this new experience is being built to scale. That said, we’re increasing our limits incrementally. To start with, our additional current limitations are:
How you can help
Thanks for helping us build a better review experience—we read every comment!
All reactions