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

[sgocastro]

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

[xxx-tx]

That's uncomfortable for me too

[iifeiss780-wq]

_ji_TP-Link_4CD

[well-known-alex]

So annoying!

[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

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

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

[iifeiss780-wq]

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

[dcumings]

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

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

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

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

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

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

[otnielyehezkiel]

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

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

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

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

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

+

[julioag-rmd]

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

[ShaunSHamilton]

I have seen this a few times as well. What I noticed is I would only be show one commit's changes as opposed to "All changes" - even though that option appeared selected.

As other's pointed out, re-selecting the "All changes" fixed the issue.

[willsmythe]

Thanks for the feedback. We're investigating.

[yawkat]

just saw this issue as well.

[chris-martin]

Switching back to the old UI specifically because of this bug.

[romain-trotard]

I have the same problem.
My Step To Reproduce is the following one:

• Click on the View it on Github in the email notification

• And then clicking on the Files changed tab

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

[owieth]

I also used to have a nice summary of all changed files for submodules:

OLD:

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

[BE-Code]

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

[willsmythe]

Thanks for reporting. We're investigating.

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

[EugeneDevastator]

can we finally have a view of file state on the moment of comment, and current state to figure out how or comment was resolved?
can we have clear links like "view current" or "view past" versions?

[hansfn]

When a file (symlink) is deleted and then a real file added again with the same name, only the deletion is displayed.

New:

Old:

[danguilherme]

I haven't found any feedback about it: I'm missing some very convenient keyboard shortcuts, namely T to focus the file filter input and CmdG to add a suggestion into a comment box.

[danielkim-moloco]

Bug: when using "Changes since your last review", if I expand the diff file (either "expand all lines" button at the top of the file or partial-expand on clicking on the folded area), the expanded version seems to show changes from "All commits" just for that file.

[pf-paul]

I saw this too, and then when I tried to comment on one of the expanded lines, I got an error saying I cannot comment on that line because it's not part of the diff, even though the UI clearly shows the line as green/red.

[tmelliottjr]

I'm not sure how feasible this idea is, but something I've been thinking about it is what it would look like if comments collapsed or expanded weren't in line with the code being commented on.

For example, we currently see something like the below for collapsed comments, and you could imagine, even more space taken when expanded. I personally find it disruptive when reading changes to see those comments in line like that. You might say, I can render the changes without the comments and you'd be right, but I like to look at those comments together with changes at times.

Is there a world in which comment indicators could exist within the line number gutter and when expanded, rendered outside of the lines changed section? Not that I'm suggesting this is how it should be done, but when commenting in a google doc, the line is highlighted, made more prominent if it's the active selection and the actual comments render to the side of the commented on content.

Current

Google Docs Example

[gg-sr]

Sorry if this has been reported already, I'm not patient enough to open 1000s of commands and then Ctrl-F through them.

When adding a suggestion equal to the original text, the following error is shown:

Suggested change cannot be the same as the original line

Problem is, it also prevents any further interaction with the text box, disabling the text area and both "cancel" and "submit" buttons. This seems like a bug because the "submit" button displays a loading indicator that never ends.

[Arshadiqball]

I really like how the new UI surfaces draft reviews and speeds up navigation—feels a lot smoother. What still feels clunky is jumping between multiple comment threads on the same file. Something like a sidebar “comment navigator” (next/previous thread, unresolved only, etc.) would help keep context without scrolling endlessly. Almost like having a table of contents, but just for feedback.

[mustmodify]

I find myself going back to read the PR description at times. Like past UI, I have to scroll to the top of the screen (which for a longer PR is awkward) to get to the "Discussion" tab. Not terrible but also seems fixable.

[mustmodify]

I just had to do this again -- I was reviewing my own PR and then wanted to go verify whether it needed dev approval or whether it had already been approved since last change.

[emilypastewka]

line spacing being bigger means fewer lines of code render per unit of space. ouch. why?

[coreylight]

I don't seem to see the CODEOWNERS file validation like I can in the old experience.
Old:

New:

[thaJeztah]

I'm confused about the change of of the colour scheme;

Previously a "yellow" / "orange" file meant "modified", and "grey" file meant "move"; which made sense as grey attracts less attention, and for renames without code changes it's "nothing to see here".

But the new colour scheme is the EXACT reverse; now "grey" means file has changes, and "orange/yellow" means the file moved 🤔

[stefanofornari]

During a review, I'd like to be able to add comments in any line of the file even if not changed.

[rdeago]

When a comment is in a file whose diff is not displayed because it is too large, "jump to comment in the diff" from Comments does nothing. It probably has no anchor to redirect to, or the anchor is not there because the diff has not been rendered.

It would be very nice if, maybe after asking for confirmation, the diff would be rendered (just as if the user clicked on "Show diff") before jumping to the comment.

[katieclaiborne-duet]

Will "Changed since last view" badges still appear on the headers of files that have changed since being marked as viewed? I find the badges helpful for reviewing large pull requests, and think I've observed them being only intermittently available during the new experience rollout.

[da3dsoul]

I don't see anyone mentioning mobile. It does not work, generally. It is zoomed all the way out