Improved pull request "Files Changed" experience feedback

[Akash1134]

Important

We’re actively investing in performance improvements for the new File Changed page, and as part of that work, the single file mode will be removed as the default view for large PRs (will still be optional) in the next couple of weeks. We know it hasn’t been the smoothest experience, and we appreciate your patience. It was only a temporary workaround for large PRs while we built a more scalable, long-term solution, which is now work in progress.

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:

• Applying multiple suggestions at one time (i.e. batching)
• Reviewing a single commit
• 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
• 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!!!

[dcumings]

Also the comments disappear from context when changes happen. It would be nice to be able to see them after changes happen. Bitbucket had a great implementation for this

[Bangkah]

yes

[William-Aspen]

Azure DevOps had a strong implementation of this. For reviewers, it’s critical to know whether their comments were applied as intended, and seeing them directly in the updated files makes that process straightforward.

[mostafaraihan]

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.

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

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

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

[maaicondgl]

I agree.

[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

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

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

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

[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

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

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

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

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

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

[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 🙏 )

[KeithYeh]

1. I can't find "comment on this file" button in new UI

Old UI

2. How to hide alerts? I can toggle alerts by pressing "A" in old UI

[willsmythe]

Thanks for the feedback. Both are known issues we're tracking.

[airvision-tw]

Indeed! I am also missing this functionality in the new view.

[cristinadoroftei]

True, I use the "comment on this file" feature quite often and I switched to the old view just because it's missing on the new one 😿

[Smolyan91]

+

[xmfcx]

How to hide alerts? I can toggle alerts by pressing "A" in old UI

This is very important for me.

[julioag-rmd]

On the Files changed tab I can only see 19 files out of 66. Why?

[lucagiovagnoli]

Switched back to the old UI specifically because of the "Files changed" bug. It's pretty risky to review thinking it's all changes, but really it's only one commit.

[justingrant]

Confirmed that this bug still exists. Here's a more comprehensive repro, and showing the workaround which is to filter to a different commit, then to reset the filter to show all commits.

1. Click "View it on GitHub" link from email notification
2. Click on "Files Changed (11)" tab

Expected: see changes for all 11 files
Actual: only shows changes from one file, even though the commit filter claims to be showing all commits.

3. Click on Commits tab again
4. Click back to Files Changed (11) tab

Expected: see changes for all 11 files
Actual: No change from above: only shows changes from that commit

5. Click on Commits tab again
6. Filter to only one commit
7. Now reset commit filter to show all commits
8. Click back to Files Changed (11) tab
9. Finally, it works normally! All commits' changes are shown.

[justingrant]

@willsmythe Given the severity of the issue and the fact that that it's been present for at least 3 months already, I assume that fixing this (or finding a repro?) is hard. Do you need any more info to repro and fix this? I can repro it easily.

As mentioned by others above, this bug kinda makes the new UI dangerous to use so I'm gonna have to turn it off soon, which is a bummer. Please let us know when this issue is fixed so we can all turn the new UI back on. Thanks.

[anna-intellegens]

This has been driving me crazy. It happens every time I follow a link from an email, which for me means almost every time I go to review something I now have to remember that the UI is lying to me, which is infuriating!

[mdfox20]

Also switched back to the old UI because of this! I almost always open PRs from the email link, so this is a completely breaking bug for me.

[vengut]

I used to be able to click on a useful link to see the submodule diff in PRs but now its just plain text.
Old:

New:

Could we have that back pls?

[cdunford]

👍 any of the above; missing being able to see what changed; I have to flip back to do the old experience to do it

[Lachy-Antero]

Our release process heavily relies on the ability to click through to see the commit diff of submodules. Will be very sad to see this go.

[hsl0]

I want to see that nice summary of changes for non-GitHub hosted submodules, too.

[jlc6]

I would like to be able to see which commit I’m starting from and which one I’m going to in the changed submodules, as the old interface used to show.

[AminHeidaridahoee]

I also want to see the submodule commitId change in the file preview, it is necessary for our code review

[BE-Code]

It doesn't always seem to remember if hide whitespace was turned on.

[Scramle]

Currently, I think the toggle is just backwards. "Hide whitespace" turned on sets the query param to ?w=1, and turning it of sets it to ?w=0. Expected behaviour should be the other way around. So in @rmartins0's case, that link works as it should, as w=1 shows whitespaces and w=0 hides them.

[shahmir-oscilar]

I believe i was able to reproduce this. See steps at: https://github.com/orgs/community/discussions/163932#discussioncomment-13915305

[FeBe95]

Related: https://github.com/orgs/community/discussions/163932#discussioncomment-14012281

[warwick-kiwibank]

A certain order of the URL parameters triggers this bug. This works:
.../files?w=1&file-filters%5B%5D=.yml&file-filters%5B%5D=.tf

But if I put the hide-whitespace parameter after the file-filter parameters, it doesn't work:
.../files?file-filters%5B%5D=.yml&file-filters%5B%5D=.tf&w=1

The parameters are added to the URL in the order of selecting the options in the GUI. So, to avoid the bug, you need to show/hide whitespace, then apply file filters.

The old UI works as expected.

[Bangkah]

Same issue here on Win 11 + Edge 124. Worked after disabling “XYZ” flag. Thanks for the workaround!

[askolesov]

I really miss the ability to go to the next not reviewed file. Also it would be great to see which files are reviewed or not in the file tree.

[jsoref]

If you uncheck the viewed files option then this flow just works: https://github.com/orgs/community/discussions/163932#discussioncomment-15212174

[pvdz]

In the single file mode

• going to next should have an option or separate set of buttons to skip reviewed files
• clicking refresh should not kick you back to the first file
• the file side bar should indicate which files have been reviewed and their size, since you no longer have a single view of that

Overall, I don't like the single view at all. I use browser-based text search a lot to navigate around diffs and both the single-file flow as well as react in general make this impossible now. Huge regression as far as I'm concerned.

/unsubscribe

[jjloneman-jetblue]

When there are a lot of changes in a PR:

And once I've scrolled down and reviewed all the changes:

There is no easy way to scroll all the way back to the top to then submit my review or go back to the other PRs.

Like in GitHub Docs, for example, there is a "scroll to top" button that appears which is very useful:

[jmos-chargelab]

I find collapsed-by-default comments really frustrating. Often, the main reason I'm looking at the diff is to see comments in context. It took me a long time to discover the little disclosure buttons on the right side of the diff. There's usually no reason for me to look at the right edge of the diff (on a wide screen and with standard line length limits, it's very far away from the main content), so even now that I know they're there, I find it very hard to scan the PR and find the small user icons where the comments are. I haven't found a way to auto-expand all comments, and the "Comments" sidebar has many issues described already here (in particular, the "Jump to comment in diff" button frequently does nothing, including when the comments are collapsed, so it does nothing to help me find the comments' context).

[jmos-chargelab]

Of course, after I've posted, I find the "Minimize comments" setting I can disable 🤦‍♂️ I think my other comments stand however, when comments are minimized the experience is frustrating!

[seve]

clicking on the PR title to scroll to top isn't working for me in the /files view. It will add #top to the url path and scroll to the top, but then it will scroll back to where i was after a second or two.

[GavynElrick-Joist]

Having a cap on comments displayed has become an issue in my teams pipeline due to its requirement to have some note on each file as a sanity check or explanation. Can we can a configurable limit so we understand that yes there will be a performance hit but in the old method we could still see all the comments no matter the number.

[jsoref]

I'm trying to review https://github.com/rancher-sandbox/rancher-desktop/pull/9632/changes?show-vendored-files=false#r2611078398

I don't think the animated greeking will resolve.

I can load https://github.com/rancher-sandbox/rancher-desktop/pull/9632/changes?show-vendored-files=false&show-viewed-files=false#diff-ccd3e520cb49f587708090deb8eb478fecf08fe874a6ad8d07d307d83e1efbbd (or an equivalent, see complaint about greeking)

I can scroll to and hover over this:

When I click, the right sidebar goes away, leaving me with:

Neither clicking on the heads nor clicking the jump to comment thing work:

But, what does happen is that when I click comments again, I'm scrolled back to the TOP of the comments list.

[kkitadate]

When viewing a single commit in the "Files changed" tab,

in "files," you could use the p/n key to shortcut prev/next.
(URL: github.com/{org/repo}/pull/{pr-number}/files/{commit-hash})

This isn't possible in "changes."
(URL: github.com/{org/repo}/pull/{pr-number}/changes/{commit-hash})

[giorgiopagnoni]

p and n keyboard shortcuts (for going to previous/next commit) do not seem to work for me anymore. They work in the old experience.

[nMustaki]

When reviewing commit by commit, it's quite slow, because one has to:

• click on the button
• click on the selected commit
• visually parse the content of new popup
• deselect the currently selected commit
• select the right new commit
• wait for the page to reload
• rince, repeat...

I'd love two buttons, "next commit" and "prev commit", or a revert to the previous menu (with multiselect enabled)

[stevenh]

I love the file by file view on PRs with large number of files, makes it much quicker to load and easier to review.

[AtkinsSJ]

The projects I maintain use a rebase workflow where commits are preserved and we care a lot about the quality of those commits. So, we review one commit at a time. It'd be useful if the "prev/next" buttons were available at the bottom of the page as well as the top (either a second set, or putting them in the sticky header).

I do really like that the "Submit review" box now lists the pending comments! That's very helpful.

EDIT: Kind of a bug report: If there's only one commit in a PR, it seems to be impossible to view the changes with the commit message visible.

[lkraav]

Landed here from y-day's update https://github.blog/changelog/2025-12-11-review-commit-by-commit-improved-filtering-and-more-in-the-pull-request-files-changed-public-preview/

Should've joined months ago, my bad.

Well, at least this screen is on y'alls active radar. Bits and pieces are coming along, but comment management (esp. with CI bots participation) is by far the biggest UX problem for our review team.

Even as of today, comment overlay on a simple 2-file PR

• ignores me disabling "Unresolved" or "Outdated" filters, just continues to show everything, spamming me to all hell.
• clicking into "1 reply" link to see what it's about simply does nothing, whereas I would expect it to navigate me somewhere in the Files list anchor.
• various code suggestions are shown full-length, I need to scroll like a mile (or rather, kilometer) down just to reach Comment no 2 - why not collapse code blocks some more for a "preview" experience?
• it's a real real real struggle to get a solid grip on "What's still unresolved in this PR", esp. when comment counts reach into multiple 10s of items.
• ⬆️ related: sometimes I want to keep a convo perma-open for future selves, so we don't forget important things if a future bug touches some currently processed topic. Maybe I'm looking for some kind of a "Pin" function here? Resource for new functionality is probably scarce, so Just leaving convos open would work fine, too, if only general comment management of it all wasn't so broken.

Hopefully someone's listening 🙏

[benryan1790]

I really do not like the single file view. Hopefully this will be a toggle in future

[aleksanb]

Doesn't work for large PRs (large diffs per file, many files changed).