Would pinning the Comments side panel to the side of the page work for you? This is something we are exploring, but recognize it will leave less horizontal room for code (since the panel would live next to the code and not on top of).

Just hit this I think from the description - it would be great to see "outdated comments" on the new revision (post feedback addressal) if possible/have the ability to toggle it. I understand the location of where the comments were initially made no longer be the same but in general they would still be helpful even if there are in the close vicinity. There would obviously have to be some handling of edges cases i.e where the line number doesn't exist anymore etc.

Overall this is a great re-haul - tysm!! 😄

It looks like VSCode's GitHub Pull Requests extension is able to do - it would nice to have continuity between the two ;)

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

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.

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

@rtalexk We’ve just updated this to fit more content in the sticky header on smaller viewports. The branch name might get truncated depending on the size, but you can hover over it to see the full name in a tooltip.

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

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.

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

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!

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!

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.

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.

Would love it to be user-level preference.

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

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.

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.

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

Any workarounds to obtain permanent urls?

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

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

What VSCode extension did you use for code review?

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

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.

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

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/

Files below is preferable IMO for a more consistent experience

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

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

Agree with all previous comments. Great feature and would be nice to get the info easily that it's WIP for the new interface.
Fun thing: I temporarily reverted to current UI in order to add a file-level comment in a PR and then back to new UI for the rest of the review. Worked fine, the file-level comment was correctly listed in the side bar when submitting the review and alongside other comments once the review was submitted. Obviously not a long-term solution but just an FYI.

+1

+1

+1

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/

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

thank goodness

Thanks for the feedback. The line-level Copilot actions are available on the actions menu (which is available when the line(s) is selected):

The "Copilot" button in the global header has replaced the "Ask Copilot" button on the Files Changed page. It similarly attaches the current PR to the chat context, but does not offer the same multi-select checkbox of files to also attach to the diff. Is this (start chatting about a PR and with one or more specific files) important to you?

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

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.

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.

Thanks for the feedback. We'll address.

Clarification: the line may not have been in the diff from the selected commits; it's in a minimized section on page load but shows up as diff if you expand the file upwards, and has the comment action available. It should either not show as diff at all, or should allow functional commenting.

From further experimentation the bug may be that expanding the file then shows changes from all commits instead of the selected commits