Improved pull request "Files Changed" experience feedback

[Akash1134]

Important
You can opt in to the public preview from any pull request via “✨Try the new experience” in the upper-right corner. You can return to the classic view by clicking the “switch back” link.

About the new experience

This refresh focuses on performance, accessibility, and clarity so reviews stay responsive—even on the largest pull requests.

What’s new ?

Performance 🚀

• Faster diff rendering with significantly lower memory usage.

UX ✨

• NEW: Comment and annotation indicators appear in the file tree to help you quickly identify files with comments, errors, or warnings.
• NEW: Pending comments are shown in the review submission panel so you can look over your comments before submitting.
• NEW: Local draft comments persist across page refreshes.
• NEW: Seamlessly switch between split and unified views.
• NEW: A new side panel helps you discover comments, including the ability to search for text while also providing quick access to errors and warnings (i.e. annotations) reported by status checks.
• NEW: The file tree is now resizable so you can take advantage of your larger display.

Accessibility

• NEW: Consistent keyboard navigation and screen reader landmarks added for better accessibility.
• NEW: Increased line spacing for readability—use Compact line height if you prefer a tighter view

What's missing? 🟨

As of the initial public preview release, there are some temporary limitations that will be addressed over time:

• Comment at the file level (including binary files): IN PROGRESS
• Rich diff previews for images (SVGs, PNGs, etc) and markdown WORK STARTS THIS MONTH
• Applying multiple suggestions at one time (i.e. batching)
• Reviewing a single commit
• Code scanning alerts
• Annotations on unchanged files
• Small screen (e.g. mobile device) responsive layout

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:

• Limited to 300 files
• Comments: 40
• Replies per comment: 20
• Alerts: 50

How you can help

1. Report bugs, edge cases, or usability pain points in the replies (screenshots/gifs welcome).
2. Tell us which future enhancements would make the biggest impact on your workflow.

Thanks for helping us build a better review experience—we read every comment!

[willmarcondeseso]

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!!!

[erikpragt-connectid]

Same here: I just tried out the new approval process, and now there is this big sidebar. That is quite horrific, please get rid of it, I reverted immediately back to the old UI.

[shihui-huang]

Same here, it took me long time to find "Only files owned by you" button. I thought this feature has been dropped.

[bashsarn]

same

[claduclad]

review sidebar is AWFUL. Please never deploy it to prod.

It is inconvenient to me too, not sure if necessary, since the old context menu was more localised, I have a 17inch laptop and I still feel it just makes my eyes have to go all over and adjust, what if I'd have a 2k display. maybe it's habit but I think it's just too much spread out

[sgocastro]

Same thing, as I see it, I think the review drawer is unnecessary and absolutely uncomfortable.

[rtalexk]

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.

[rtalexk]

That's perfect, as soon as it has the Copy button it is fine. Thank you!

[nniesen]

Similar scrolling issue getting back "Conversation" or "Submit Review" when far down in a large PR. Maybe those could move over into the side navigation or maybe the sticky header briefly becomes a floaty thing when scrolling.

[RentecJeremy]

I came here just to comment "Thank you for the branch name in the sticky header". I can't tell you how many mammoth PR's I've had to scroll up, or duplicate the tab, or (insert method of getting branch name here)... now the branch name is just there and copy-able. 🤌

[albertoblaz]

Similarly, I miss having a sticky bar below the PR's title to have the "Conversation" tab/button visible without having to scroll bar to the top.

Alternatively, users could still do Cmd+Up to scroll up and then click on the tab, but doing so doesn't scroll if the focus is on the diff panel, so you need to click on the files sidebar or the page margins and then use the shortcut.

It's not a critical issue, but a little annoying.

[rtalexk]

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.

[aricwalker]

That's great to hear and great suggestion! I agree it could be useful to have comment indicators at the file level especially when scrolling through "viewed" files. We'll take this back to the team to discuss. Thanks for the feedback!

[ScottRitterDns]

Totally second this. The current enhancements for the ability to review your own comments is a game changer. The ability to scan large PRs through all the collapsed (viewed) files would be the final cherry on that cake!

[shekibobo]

Building on this, it would be great to also see outdated comments on a file in a dropdown, so even if they're outdated and don't show up inline in the file diff, they could still be found within the file context.

[thornevale]

It would be helpful to have a dropdown in the file view that shows outdated comments too. That way, even if they're not shown inline anymore, we can still find and read them in the context of the file.

[maaicondgl]

I agree.

[rtalexk]

Seamlessly switch between split and unified views.

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.

[fmichaut-diff]

Seemless switching would surely be a nice to have, but user level preference is a big big QOL improvement !

[smil2k]

Thanks for the feedback.

• We are planning to support seamless switching of "hide whitespace-only changes", but no timeline yet.
• We are also exploring the implications of making this a user-level preference so it would be remembered/applied consistently across all PRs. Do others have thoughts/opinions on this?

There are 3-4 chrome extensions to fix this missing feature. Please implement it as it is very annoying to set it each time.

[ryansheabla]

Thanks for the feedback.

• We are planning to support seamless switching of "hide whitespace-only changes", but no timeline yet.
• We are also exploring the implications of making this a user-level preference so it would be remembered/applied consistently across all PRs. Do others have thoughts/opinions on this?

Would it be possible to set "Compact line height" as a user preference as well? I like the changes overall but much prefer the original setting.

[jessehersch]

Thanks for the feedback.

• We are planning to support seamless switching of "hide whitespace-only changes", but no timeline yet.
• We are also exploring the implications of making this a user-level preference so it would be remembered/applied consistently across all PRs. Do others have thoughts/opinions on this?

please do this soon. it's been too long! This discussion is 4 years old, and it says the feature was asked for 3 years before that! So long that the original feature request is a dead link. https://github.com/orgs/community/discussions/5486

[Primajin]

It was actually working better in the old flow and there was even a blog post from Github: https://github.blog/changelog/2021-10-14-hiding-whitespace-is-now-remembered-for-each-pull-request/

[rtalexk]

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.

[aaccioly]

Any workarounds to obtain permanent urls?

[arisacoba]

@rtalexk which browser are you using? Clicking the line number should just highlight the line, not open the add comment flow.

[rtalexk]

I'm using Arc Browser, but this isn't happening anymore. 👀

[thuringia]

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 a to hide them doesn't work anymore.

Maybe we could have some grouping or clustering in the alerts panel in the future.
For example I would prefer to see alerts raised by the linter first, instead of "this line is not covered by tests".

[eugenet8k]

What VSCode extension did you use for code review?

[JasonZhuWTG]

What VSCode extension did you use for code review?
I think 'GitHub Pull Requests'

[audreyality]

unfortunately it looks like pressing a to hide them doesn't work anymore.

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.

[willsmythe]

Thanks for the feedback. We are planning to restore the ability to use a to hide annotations.

[reecefenwick]

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

App.tsx
components/
hooks/
index.ts
styles/
utils.ts

Example of desired state

components/
hooks/
styles/
App.tsx
index.ts
utils.ts

This would mirror how the majority of developers view the code in their IDE

[willsmythe]

Thanks for the feedback.

I definitely agree that we need to avoid mixing files and folders at the same level. How would you feel about files being listed before folders (when at the same level)?

App.tsx
index.ts
utils.ts
components/
hooks/
styles/

[reecefenwick]

Files below is preferable IMO for a more consistent experience

But I also would welcome files above, it would be a massive improvement 🙌

[franzliedke]

Indeed, files below would also be consistent with GitHub's own repo tree view.

[warp10]

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.

[Nilomiranda]

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.

[bassel-shouban-rp]

+1

[willsmythe]

I don't see the option to comment on the file itself, only on specific lines.

Commenting on files is now available in the new page 🎉! See https://github.blog/changelog/2025-07-17-pull-request-files-changed-public-preview-experience-july-17-updates/

add.file.level.comment.in.new.page.mp4

[otnielyehezkiel]

this happening to me also, stuck loading after filter based on file ownership

[genesisfresa]

+1

[evenkov]

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.

I have the same problems with "stuck info" for some of my files.

[jieyouxu]

Hi, I would like to play around with this, but I'm not seeing the opt-in mentioned in

You can opt in to the public preview from any pull request via “✨Try the new experience” in the upper-right corner. You can return to the classic view by clicking the “switch back” link.

Am I missing something?

[imanmahjoubi]

We are rolling this out to users slowly, you should be able to see it soon 🎉

[margaret-lin]

The tab for Ask Copilot seems to be missing, also when hovering over lines.

[smcmanis]

Yes, I often use the multi-select checkbox to select a subset of files to include in the chat.

[zak-flex]

It could just be me, but when the copilot UI is not open and I choose "Attach to current thread", I expect something to happen. Generally, getting back to a Copilot chat after it's closed is harder than I feel it should be.

[JayLathiaTR]

This is an important functionality, where I just ask the Copilot by selecting all files saying - 'What are these changes about and scan for any security flaws for these files'.

So yes, this is required for sure, and this is the only reason - I am not using the new 'File Changed' feature.

[sylv256]

I'd love there to be less shoving AI in everyone's faces and more of this. As soon as I realized the Copilot button wasn't bugging me toward the right of the line of code I hover over, I was happy.

[vitorklock]

My team has the process of always asking Copilot "Any mistakes made? Review this PR" before doing manual reviews.
Just like @JayLathiaTR, I think that being able to talk to Copilot about all the changes is an important feature.
This would also be an improvement, because previously I had to manually click all checkboxes, sometimes more than a hundred of them.

[njvrzm]

Not sure if this is the sort of feedback you're after, but the :shipit: emoji does not preview in the review textbox in the new version 😅 . It does show up correctly in the preview.

[willsmythe]

Thanks for the feedback. We'll address.

[atulkumarr123]

How do I hide all the comments of a file completely in one go, Rather than just collapsing, just like we used to have in older UX?

[rounak-openai]

⌘ + up arrow no longer scrolls to the top in the pull request changes view

[mayonfrancis]

We have a Changed since last view pill, at a file level. Would be amazing if we could also add: What actually changed since last view
(ie, the code diff instead of just the pill)

[mpg-kazuhiro-kobayashi]

I didn't notice the warning icon next to the file names at first.
If there are warning comments, I’d prefer them to be visible by default.

Initial view	View after expanding hidden diffs

[davidallada]

On a large format monitor, when you mark a given file as "viewed", its really hard to tell when just looking at the file names on the left hand side of the screen which are "Viewed" and which are not. I think it would potentially make sense to slightly change the color or add a check mark or something to the left hand side where the file names are to indicate that a file has been "Viewed" apart from the viewed check just being on the far right screen

[WiseNat]

Diffstats seem to be broken on my end - unless the red/white square is intentional?

Old

New

[ldemailly]

about the red/green square any explanation of what they actually mean precisely ? (more precisely than https://github.blog/news-insights/the-library/improved-commit-diffs/) specifically re number of empty squares

[paulca]

Pretty bad lag with the "+" icon appearing in the line-number gutter on Desktop Safari. Safari performance of PR reviews has been pretty terrible lately. Please test in Safari!

CleanShot.2025-08-07.at.18.55.24.mp4

[nojvek]

"[ ] Viewed" should be at the bottom of the file. I scroll through the file and I want to mark it as viewed, but now I have to scroll up, find the [ ] Viewed, check it, then scroll ..... all the way down. Seems too much scrolling work.

If [ ] Viewed is at end of the file, it is a natural workflow.

[inkiebeard]

even in the preview it has the existing functionality of being "sticky" so it should still be possible to tick even at the bottom of the file changes

[SuperRembo]

I'd like to be able to navigate through the files with the keyboard. Especially in pull requests with many unimportant changes.
Review a file, mark it as viewed with keyboard, move focus to next file, mark as viewed, etc. Marking a file as viewed could move focus to the next file automatically.

[kvudata]

Overall, pretty slick! I do have what I find to be an annoying pain point - the submit review button being bottom aligned requires a lot of mouse and eye movement, and the first time I popped in I actually missed the buttons at the bottom completely. It would be great if those could be brought up so it flows right after the approve/reject radio buttons.

[csilva-intakedesk]

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:

Limited to 300 files

300 files? No one is reviewing a PR with 300 files. If the issue is display limit to even less and list the files but a PR with that many files is not reviewable.

My honest feedback. Take it with a grain of salt.

[paulca]

300 files? No one is reviewing a PR with 300 files. If the issue is display limit to even less and list the files but a PR with that many files is not reviewable.

One of our PRs was a complete UI update, so it required changes to every CSS file and every HTML view. Pretty sure that was more than 300 files. I have a 150 file one from this week and a 250 file one from last week. They're not frequent otherwise, thankfully, but they do pop up!

[Francute]

There are times when you see 300+ files on a single PR. Sometimes it is a big refactor. Sometimes someone decided to add full test coverage when it had 0. Sometimes it is an untracked old repository (or is being migrated from another repository manager). Or, more commonly, on git flows that require you to open PRs against a secondary branch (like development) and then push to production by opening a PR to merge the secondary branch to the main one (like development to main)... And there are other valid reasons why you would have that many files on a single PR.

And yes, some of those PRs will be reviewed with a lot of patience, some others will just be checking for specific things before doing the merge (like looking for the global picture that feature flags well cover the features to release, or that there are no extra steps to take into consideration after the deployment, etc...). There are so many orgs out there that may have entirely different workflows from yours

[Francute]

I'm using the new UI since early July. However, I've started facing issues that didn't exist very recently. Right now, I'm currently sure doing suggestions on multiple lines used to work well in the new UI, however, this week:

Screen.Recording.2025-08-08.at.8.52.18.PM.mov

For example, I've selected lines 30 to 32 and provided a suggestion to "Remove those lines, and implement this one instead." However, the new UI interprets this as a suggestion to change only line 32 to the one I've shown.

If I do the same on the previous UI, it shows as expected:

Check that it says "Add a comment on lines R30 to R32", so it's not a missclick.

---

Then, when trying to view changes from a specific commit, it displays a select with "All changes" and "Specific commit..." options. If I choose "Specific commit...", it scrolls to the top and nothing happens. If you try to go down again, you will see a backdrop suddenly appearing.

If you slowly scroll down, you will see a broken modal going over the navbar, a flashing modal that keeps opening and closing, a modal that appears for a very short period (maybe less than half a second?), or literally nothing, just the backdrop.

---

Those are the issues I know how to reproduce. The others are randomly experiencing an issue where the function to open the box comment on a PR stops working everywhere on the website, forcing me to refresh the page to fix it. (Since I don't know how to reproduce, I can't tell if this is happening because of GitHub js, or by one of the few extensions I have). And lastly, the scroll is getting frozen by who knows why.

The issue of being unable to open the box comment on a specific line on a PR occurred only on Chrome across two different devices. The problem with the frozen scroll occurred on three devices, primarily on Chrome, but also on Firefox. Curiously, being unable to open the box comment happens more frequently.

[najibghadri]

Could we put the merge functionality in there please?

[iptvportugal8k]

Assim como no novo sistema de revisão de código, onde a performance, organização e clareza fazem toda a diferença para a experiência do usuário, no mundo do iptv também é essencial ter uma interface ágil, fácil de navegar e com recursos que realmente melhorem o uso no dia a dia. Uma boa estrutura e usabilidade tornam qualquer serviço muito mais eficiente e agradável.