می‌خواهم بتوانم در حالی که پنجره‌ی نظرات باز است، در درخواست Pull اسکرول کنم.

دلیل: وقتی یک نظر قدیمی است، باید به نسخه فعلی نگاه کنیم تا بررسی کنیم که آیا واقعاً به آن نظر اشاره دارد یا خیر.

من واقعاً عاشق این ویژگی هستم! متشکرم!!!

Yes, this should be a user-level (and per-PR) preference. It reduces review noise, improves focus, and was already supported in the old experience.

Yes

Yes +1

Did this comment feature set change? I can no longer see comments inline on the files to check that changes were applied as intended

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.

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.

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

Optimized diff rendering with reduced memory consumption.

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.

Default auto goto V2344

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

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.

this is happening for me too.

Some comments are showing up in file and some are not

where is the copilot here?

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/

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.

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

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

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.

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

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.

@willsmythe any update on when this is getting added?

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.

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';
    });
  }
});

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

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.

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:

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.

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.

Ok

App.tsx

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

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.

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?

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

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

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

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.

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

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.

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.

Thanks for the feedback. We'll address.

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

I've been seeing this since the fall which is when I turned off the new mode.. It looks like they misattribute these somehow, which is visible when you start an draft review and look at the diffs of suggestions:

Does the new "File Changed" mode still have the "Pending" problem https://github.com/orgs/community/discussions/10369#discussioncomment-14155913?

Thank you for reporting this, the team will look into it

Reviewing force pushes (in addition to the misleading "Pending" review problem https://github.com/orgs/community/discussions/10369) was what made me avoid the "Review" flow, also in the "Classic" view.

The thing that worked in the "Classic" view was: 1) keep adding and responding to comments independently of the "Review" flow 2) include enough context in the comments so in the future one can roughly find the place that is being commented on. This is hard to achieve since we don't have ability to comment on unchanged files (https://github.com/orgs/community/discussions/9099).