Improved pull request "Files Changed" experience feedback

[Akash1134]

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:

• Comment on any line: You can now comment on any line of a changed file, not just the lines surrounding a change.
• View the description without switching pages: You can now view the pull request description from the new Overview panel on the "Files changed" page.
• Reviewing made easier
  • Enhanced file tree: The file tree is now resizable with indicators showing the files with comments, errors, and warnings.
  • Review your pending comments: Pending comments are now shown in the review submission panel, so you can double-check your feedback before submitting.
  • Draft comments: New comments and replies are saved locally so you won't lose them if you accidentally close your browser or refresh the page.
• Fewer page reloads: Clicking Refresh to pull in new changes, switching between split and unified modes, and other tasks will no longer force a full page refresh.
• Accessibility & readability: Keyboard navigation, screen reader landmarks, and increased line spacing options are now available to make the experience available to everyone.

✨ Updates

See what's been fixed and improved since the launch of the public preview:

• June 26: initial changelog
• July 17: file-level commenting, performance fixes, diff loading and expansion issues, and more
• July 31: rich diff support, improve file tree ordering, and more
• August 21: improved review submission panel usability, submodule support, and lots of fixes
• September 11: temporary single file view to improve scale (see message above)
• September 25: commenting on unchanged lines 🎉 , single file mode improvements, and more
• November 6: apply suggested changes in a batch, collapsible annotations, and more
• November 20: new Overview panel (for viewing PR description), performance and other fixes
• December 11: review by commit, improved commit filtering, filtering improvements, and more
• January 23, 2026: default experience for all users, new experimental mode that uses virtualization to support larger pull requests (up to 3,000 files)

🟡 Limitations

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

• 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 1,000 files in single file mode or 3,000 in experimental mode
• Comments: 40 in the page (but up to 350 in the Comments side panel)
• 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!!!

[Frames254]

Yes

YES

OKAY

[Frames254]

Yes

YES

OKAY

REALLY

[Frames254]

Yes
wHY

YES

OKAY

REALLY

[Abdullah9990]

Yes

[Baxrom0311]

yes

[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.

[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.

[pakeeza2425]

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.

[duduedufsa]

This update focuses on three essential pillars of a modern code review experience: performance, UX, and accessibility.

Optimized diff rendering with reduced memory consumption.

[Endy0611]

This update focuses on three essential pillars of a modern code review experience:
performance, user experience, and accessibility.

We’ve optimized diff rendering to significantly reduce memory consumption,
resulting in faster load times and smoother navigation when reviewing large
pull requests.

[vivoysg372-source]

Default auto goto V2344

[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.

[iifeiss780-wq]

https://github.com/orgs/community/discussions/5486

[dcumings]

[shrynshjn]

this is not showing up for me, rather i am getting a comment option on the pr level, having it on a file level would really be great, current i open two split windows to check my older comments and the latest code.

[eengelhardt]

this is happening for me too.

Some comments are showing up in file and some are not

[xiangsgao]

where is the copilot here?

[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.

[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/

[pakeeza2425]

The old flow worked better because features like "hide whitespace" were remembered per pull request, as GitHub highlighted in their 2021 blog post
. The new experience seems to have lost some of that convenience, so restoring those capabilities would improve usability.

[mustmodify]

remembering per-user and per-PR seems both obvious and would result in a significantly better experience.

[ericgreveson]

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.

"Hide whitespace-only changes" as a user-pref sounds good.
Regarding line spacing, currently, compact mode is an option but the default is to be "extra line height". I feel like "Compact line height" should be the default (to match the current experience, but also because the greater code density from compact mode is in my opinion likely to be more useful to more people when reviewing, compared to the accessibility-focused greater spacing).

[msmygit]

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 Files Changed view without showing the review comments or their replies.

[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".

[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.

[mccrearyp]

@willsmythe any update on when this is getting added?

[jsync-swirlds]

In addition to using a to hide annotations, can we have a global (user) setting to hide annotations by default?
Having to tap a (which does not always work correctly, particularly for large diffs) for every PR in repos that overuse annotations (a distressingly common practice that makes review a painful chore) is irritating and we're still left with (often) dozens of files that now have no visible change because some irrelevant annotation happened to touch that unchanged file.

[mccrearyp]

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:

document.addEventListener('keydown', (e) => {
  if (e.key === 'a' || e.key === 'A') {
    document.querySelectorAll('.InlineMarkers-module__markersWrapper--Fw1hl').forEach(el => {
      el.style.display = el.style.display === 'none' ? '' : 'none';
    });
  }
});

[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

[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.

[parasyte]

I recommend sorting the same way as git diff-tree, which is what I think the old view did.

$ git diff-tree -r ..main
:100644 100644 d68e1befa16c82c562359a15a283a838d72b0727 e24eac8e828629741b34632e9ef2493a9a95d753 M      src/cryptosuite.rs
:000000 100644 0000000000000000000000000000000000000000 9ad4b1337b54bf28686cf4becccac13124fe6747 A      src/cryptosuite/bip340_jcs.rs
:000000 100644 0000000000000000000000000000000000000000 ab474845d58506540e0ac7e6f0e287770efa1b41 A      src/cryptosuite/bip340_rdfc.rs
:000000 100644 0000000000000000000000000000000000000000 92337d2e16e7ec1f1d2ebc0836773c2099538a1d A      src/cryptosuite/transformation.rs
:000000 100644 0000000000000000000000000000000000000000 fa9ba63738d7b46f5f4647deb01328f6b6981777 A      src/cryptosuite/utils.rs
:100644 100644 f016785749ea50aeb255c80d1a08c1f53b108f6e cd40229a1055c0bd102c6f47318b0d874ab83610 M      src/document.rs
:100644 100644 8b798f1b9f21f3699cdd399939664e9ef4744a8d e2de154c3a730a5b055d6e944e0b8adb98e26f57 M      src/update.rs
:100644 100644 8c80fd426222a68987e2938d37549005bc9db2a0 9c98405bb3803c789dd49a23ca291f2fd9b774cd M      src/zcap/proof.rs

Old view:

New view:

[richard-rance]

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 vendor folder containing a copy of all dependencies. It would end up at the end of the PR which is perfect since I basically ignore it when doing a review. Right now I have to scroll past all the vendor files to get to the top level files. That can lead to them being missed.

[sethrh]

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

[Citation needed.]

I'd prefer the ordering stay the way it was. But developers are an opinionated bunch, so if this is going to change there should be a way to set preferences. Besides, there are also other options besides just alphabetical and alphabetical by folder that might be useful, such as eliminating the tree view altogether and just showing file paths or even just file names.

[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.

[Asfand6417]

Ok

[iifeiss780-wq]

App.tsx

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

[ia0-review]

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.

[adcoelho]

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?

[glureau]

Workaround I've just found, go back to old experience, then load again the new experience.

[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.

[rr-jimmy-multani]

I'd prefer that this button stay since it's related to the PR and its changes.

[daira]

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.

[3nprob]

Bug: This button is visible even if Copilot is fully disabled in user settings.

[Biglulux]

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.

[kanonji]

Because my team is understaffed, I often have to review PRs that use languages, frameworks, or libraries I am not very familiar with.
For that reason, I rely heavily on "Ask Copilot about this file-diff" (the line-level Copilot actions).
Even if I can understand the overall design and structure, I do not know the fine-grained syntax or how specific library methods behave.

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.
If I use it 10 times in a single PR, that is 10 clicks vs. 30 clicks.
If I review 10 PRs, that becomes 100 clicks vs. 300 clicks.

For me, the version where I can use "Ask Copilot about this file-diff" with a single click is clearly better.

[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.

[cmargonis]

On the topic of emojis, I really liked that I could type e.g. :idea and it would suggest the 💡 emoji. It would be great if this functionality were preserved (or even expanded upon 🙏 )

[barney-s]

Please add the ability to abandon a review in the new version of the UI as well.

[danawoodman]

i'm sorry to be blunt here but this has to be the worst UI for a reviewer checking on their PR feedback...

it is so easy to miss feedback inline while re-reviewing code which compounds with large PRs. the icons are microscopic and get lost in the noise of the diff

don't think i'll ever switch over to the new UI voluntarily until this is improved

[jbrunton]

This is also putting me off the new experience. I don't mind having an option to collapse comments, but right now the "Expand comments" option which comes up in the context menu seems to only expand a single comment. I keep missing comments because they're hidden to the right of my monitor.

Ideally it should be possible to expand or collapse all, and to keep that preference saved between PRs.

[robinbijlani]

This absolutely drives me crazy. I constantly am about to add comments on the same exact line someone else already wrote a comment on, because I totally don't see the tiny icon.

[dgoldstein0]

I think this is because you've selected the collapse comments option? I believe expand comments undoes it. It's annoyingly easy to accidentally trigger because it's bound to some single-letter keyboard shortcut, and it remembers it across page loads. FWIW I agree the comments collapsed option sucks but with them expanded I like the new experience quite a lot.

[jeffhandley]

Echoing this feedback -- I came here to report the same frustrating and found this comment. I suspect in the 2793 hidden items immediately above this, the same feedback found be found repeatedly.

The old UI makes it much easier to scan through large PR reviews and engage in conversations along the way. The new UI makes it far too easy to overlook discussions. And the Comments pane does not reliably let me jump to the context of the comments--even when it does, I'm not seeing it expand those comments as I'd expect it to.

Ultimately, I really want a view for All Unresolved Comments Expanded that I can save as a preference.

[adamgaynor]

Please add back the "Only Files Owned by You" filter. Without it, the new experience is frustrating when reviewing large PRs worked on by multiple teams.

[adam-sandor]

This! I came here to make the same request. This is a critical feature for me.

[robinbijlani]

Working in a monorepo with many different CODEOWNERS, we would be forced to create a Github Action to provide something similar to this functionality in a PR comment if you take it away.

[alex-sage]

My company has recently switched from Gitlab to GitHub and I am frankly shocked at how abysmal the PR review process is on here.

In its current state, it is borderline unusable.

The main problem is that it's almost impossible to address comments in a review that are asking for changes in a reliable way.

• As soon as the requested change has been made on the referenced code line, the comment gets disassociated from the code and disappears from the "changes made since last review" for the reviewer. This makes it very difficult for a reviewer to check if their change requests have been addressed appropriately.
• The PR creator can only reply to review comments made on code lines that have not changed. Even replies to comments/threads that have been made before implementing the changes disappear from that thread as soon as the change is pushed (at least if they wait with publishing until the comment is actually addressed as promised in the response).
• For some reason not apparent to me, some review comments don’t appear at all in the “conversation” tab. It can be very hard to find those at all. And it seems that again, replies to them (even though shown as a reply in the thread initially) will be added as a standalone comment only associated with the code line, not with the initial review comment once submitted.

There are other issues, like the inability to create threads (that have to be resolved) with general comments not associated to a specific line of code. But just the two points mentioned above are so fundamentally important to a PR review process that they make reviewing PRs on this platform a huge pain. For an established platform like GitHub it should be absolutely unacceptable to have such a core feature (arguably the main reason to use a platform like this in the first place) not working properly.

How are people even doing PR reviews with multiple cycles on here?

[nhecker]

On Firefox in the new experience, I cannot copy suggested changes in a comment made by Copilot if I want to paste them somewhere else. This is possible in the older UI/UX.

[eysikal]

I miss the ability to mark a file as viewed. Did we lose that or has it just been moved somewhere?

[eysikal]

Wait...maybe I was just looking at a single commit's diff.

[imanmahjoubi]

@eysikal yes currently it is unavailable for commit by commit view, but it is on the list. Thank you

[kudlav]

Why is there the You made it to the end! footer with animation? It's distracting and useless. I don't want to feel like in a kindergarten when using GitHub.

[gps035]

I added a one-line change suggestion in a comment without leaving a review, on a line that isn't currently changed in the pull request, and it renders as a suggestion to add the line where there was nothing there before.

[robinbijlani]

I'm seeing a lot of usability issues with the new interface (already mentioned in threads here), but when I switch back to the classic one, I get this vague message? Why would I not be able to see comments in both views?

[dabrahams]

It's completely broken. The button at the top of my PR says 45 comments. I click to look at comments in the Panel. The first one has 3 replies that aren't showing in the panel so I click the replies button. Panel closes and the screen sometimes jumps to a place; whether it jumps or not, I don't see the comment. The originalbutton now says 59 comments. The feature has “AI ✨” all around it and its implementation with AI shows. I hate what this tech is doing to software.

[alexandrachakeres-wk]

I made a comment on a PR that shows up on the PR's main page (and in the Files Changed tab diff if I click on my avatar on the line I commented on), but doesn't show up in the new Files Changed tab Comments panel. It doesn't matter if I filter the comments there by author / whether they're outdated or resolved (the missing comment is neither). This is the reason why I had opted out of the new Files Changed view months ago, but it doesn't seem like I have that option anymore. The new Comments panel is un-useable.

[simon-abbott]

For some reason I can't add a comment to a three-line section. If I click and drag the plus I can select a 2 line block or a 4 line block, no 3. Given the number of three-line statements out there (preamble, content, end; like an if statement) this is incredibly frustrating.

[majestic-owl448]

Suggestions are not visualized correctly, multi-line suggestions only show one line in the starting code

Clicking on a filename in the menu on the left does not bring to a file if it's lower in the list

[smnh]

Searching the contents of the files in PR using native browser search doesn't work in big PR.

It looks like that in a classic experience, all files and their contents were loaded and rendered on the page (except very long collapsed files like the package-lock.json). This allowed me to search for a variable or a function name across PR files to quickly find a referenced function.

But now, due to the performance optimizations, files that are not visible in the currently viewed scroll region are not rendered and therefore not included when I search something.

I suggest having internal search (triggered by something other than cmd+f to prevent highjacking default browser's search) that will search across current PR's files.

Alternatively, clicking on a function name would reveal its references similarly to how it works when navigating files in a repo.

[danielrh]

I still can’t check markdown checkboxes. This is a critical way we track required work for a pr.

• authors or reviewers can check boxes in a review