New commit details page (public beta) feedback

[willsmythe]

A new version of the commit details page is now available in public beta! This new page, which is enabled by default, lets you quickly understand and navigate the changes in a commit with improvements to filtering, commenting, and keyboard navigation!

What's new 🎉

Here are a few of the noteworthy changes:

• Floating comments: Code comments float over the diff when selected. To select, click on the commenter's avatar to the right of the line.
• Comment counts: To help you identify files with comments, the number of comments for a file now appears in the file tree.
• Keyboard navigation within diffs: You can now navigate around changed lines in the diff using the up and down keys on your keyboard. A new context menu also makes it easier to comment, copy, and select.
• Quick view switching: Switching between unified and split views no longer reloads the page.
• Filter by file extension: Easily filter changed files by file extension in the diff to see the content most relevant to you.
• Filtered out diffs hidden: When filtering the file tree, diffs are filtered as well, allowing you to reduce distraction and see the files you care about most.

To opt out of the preview, go the Feature Preview dialog on your profile, select New Commit Page, and click Disable.

Let us know what you think!

---

Investigating 🟨

Things we are discussing and investigating internally (and we welcome your feedback on):

• Showing all code comments at the same time (like how the original page works)
• User setting to wrap lines

Known issues 🔴

• Floating comment dialog appears outside the viewport (or causes the page to scroll when it appears)
• Page sometimes scrolls when a diff line is selected
• Page scrolls when "add a comment" dialog is opened
• Lines are not selected when link contains a range (e.g. #diff-e727e4R4-R7)
• File extension (or just .) appears before file name in header above diff
• Generated files (identified in .gitattributes not presented as generated)
• Ordering of files in the tree doesn't always match ordering of diffs
• Diff context text (e.g. function names) cannot be selected/copied
• Unable to click drag multiple diff lines (to select a range)
• Fixed-width (monospace) font user preference not honored in commenting forms
• @ mention menu does not appear when adding/editing inline comments

In progress 🧡

(updates coming)

Recent fixes and enhancements ✅

Week of September 16:

• FIXED: Full commit message not shown (hidden behind "Show More") ✅
• FIXED: Commit message text color is too light ✅
• FIXED: Diff stat visuals (green/red +/- boxes) missing in the header of each file ✅
  
• FIXED: File path above each diff was unnecessarily truncated ✅
• FIXED: Copy menu option not appearing for some users ✅

Week of September 23

• FIXED: The native browser context menu now appears when right-clicking diff lines. To access our custom menu (which now groups actions together) use the drop-down on the action bar at the right of the line.
• FIXED: When no files match the filter conditions, a message now appears (previously nothing was shown)
• FIXED: Tab indents not rendering correctly on some browsers (we also switched back to not identing wrapped lines; previously we tried to maintain the first line's indentation level, and will continue to explore this)
• NEW: A new user preference Compact line height lets you opt into a more compact line height. You can toggle it from the view settings (⚙️) menu near the top of the page.

Screen.Recording.2024-09-26.at.11.34.46.AM.mov

More about compact line height

* Compact line height user setting 🆕: * **What's our plan?** Based on your feedback about the height of diff lines in the new parge, we are adding a user setting under the ⚙️ that you can enable if you want more compact lines. When enabled, the height of diff lines will be `20px` (same as the classic commit details page), otherwise (and by default) they will be `24px`. * **Why a user setting?** It is important that this (and every) page on GitHub is accessible to everyone. [WCAG recommends a minimum of `24x24px` for click targets](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) because _some people with physical impairments cannot click small buttons that are close together_. The avatar (which appear when there are comments on a line) and button to add a comment are both important click targets on the line, which is why the default height of the line is 24px. We recognize that some users prefer (and are able to interact with) more compact lines and click targets, which is why we are introducing a user setting.

[SuperSandro2000]

My first reaction to the new page was: What is happening now!?!

My second impression was: why is everything 50% bigger, did I Ctrl+Scroll to zoom by accident?
Edit: Actually it looks a lot more like the old one when going to 90% zoom 😂

And my third was: where are the diff count squares?

Also I just found the first bug: when having text selected and trying to extend that selection with shift, that no longer works.

Also I was just searching a bit for a commit message because since it is now completely grey, I kinda missed it.

[Logan0150]

Good

[ALANthemoor]

Need help with the receipt

[yosef019]

Hello will be fix to connect all tags? 9+?
Its randomly connect to random tags sometimes 6-7-8-9
And you want be quiet for now with app not publish any video on YouTube?
And i want help with Hebrew translation

[vlad1300]

[polybiusproxy]

I personally dislike the new page's design.
As someone who likes to have things small, I browse and use GitHub at 90% zoom on my browser, and I believe this new design makes things bigger than they should, and the increase of the line height looks unappealing to my eyes.

[homira135]

چه چیزروادغام وتقسیم می کنیدکه کنم بادوتافرمو ل. وحساب کتاب خودتون میدونیدچکارکنیدباکاربران

[ringin31]

that's really

[vkoti6159]

hi this reaaly?

[pckotzer]

I cant see now how my files have been changed by size, thats not good

[homira135]

من یکسال وقت وزمان وهزینه اینترانت ندادم که امروزتقسیم بشه ویاباچهارتا فرمول سرکیسه ببندین

[Reunt]

Is there a known issue or limitation that prevents file size changes from being visible?

[Spiderouf]

حل جميع المشاكل متعلقه بجوجل ادس

[JayDi85]

1. Comment marks near file are good
2. Collapsed comments for better code review are good
3. Need additional features like: fast show/collapse all comments -- e.g. two working modes: first use for code review without comments (collapsed) and second+ uses for discussions with fully visible comments

[adlai]

@generalmimon wrote:

[...] floating comments - they seem to have been designed with very short comments in mind (e.g. one sentence)

I mostly work alone, and this form factor is good for comments that I wouldn't want in the code itself if they're too messy, but belong to specific lines of code and thus would not go well in the commit message. Think of them like sticky notes on a printout of the code, that I could take to a meeting with other developers, and move onto the whiteboard if helpful.

[junior-santana]

Thanks for the feedback, @JayDi85 !

Need additional features like: fast show/collapse all comments -- e.g. two working modes: first use for code review without comments (collapsed) and second+ uses for discussions with fully visible comments

This is something we are exploring. We would probably offer the option to show comments "floating" (like this new page) or "inline" (like the current page). Would this work?

Please add this. I've just seen the new UI and had to disable it because reviewing a large file when all comments are hidden was a pain. In the end, I had to go through each one of them to check if I had missed any.
Also, the comment button is very subtle, especially in the new design, and it's a bit buggy (sometimes it just doesn't open and the page scrolls to random places)

[freakyblack]

good feedback.

[zm1355]

good feedback

[Torin24434]

good code

[robertkirkman]

My feedback is, thank you for putting the green "beta" mark with a link to this post explaining. I like the new design, but when it happened, I was in the middle of writing comments on a commit and it was very confusing to me why the design changed. I thought for a little while that the project maintainer was collapsing my comments until I found the link to this page.

[willsmythe]

Thanks for this feedback! This new page will be fully rolled out (in beta) by today, but we have other beta features that will be shipping soon, and we'll make sure to test this flow to ensure nothing breaks (and the experience is not confusing).

[CY2-DavidW]

That's odd, because my page says "Alpha". I would argue that its live, and there is no way to toggle the page back then you can't really call it a beta.

[jacobgkau]

I appreciated the beta link to this discussion at first. Now that I've been receiving comment emails for months, I'm appreciating GitHub making such a poorly received change in the first place a lot less.

[rahcom]

Error code 500

[llyyr]

The problem (as mentioned by others), isn't the scaling, the scaling is actually the same as before.

The issue is the height and line-height set for .diff-line-row. Just let my browser figure out what the line height should be instead of hardcoding some line height.

If this is for accessibility purposes, then it should be it's own feature preview or option that the user can toggle.

Another issue that's not mentioned yet is that commits with really long descriptions now have a "Show more" button instead of just showing the full description. If I'm clicking on a commit, I probably want to read the description. Please don't make me click multiple times. The text could also be made brighter and easier to read as it was before.

See with this example commit: mpv-player/mpv@d2f3b66

[willsmythe]

Another issue that's not mentioned yet is that commits with really long descriptions now have a "Show more" button instead of just showing the full description

We rolled out a fix for this 🎉. See "Recent fixes and enhancements ✅" above.

[willsmythe]

The issue is the height and line-height set for .diff-line-row

We also just rolled out a new setting that lets you control line height (see description). Compact line height avoids adding any extra padding.

[Bilka2]

I dislike that the file name and path gets shortened despite there being plenty of horizontal space in the bar. And I can't even hover it to get the full path, I have to hover the "expand" button for the purpose of this screenshot.

[willsmythe]

Thanks for the feedback. Agree --- there's no reason to truncate the file path when there's plenty of space to show it. I opened an issue.

[willsmythe]

A fix rolled out for this last night! 🎉 Take a look and let us know if you're still seeing a problem.

[R0rt1z2]

Honestly, I liked the old design better. I hope there will be an option to switch between them.

[Justasic]

I personally agree with @R0rt1z2, I like that github now finally seems to fit the code view to the full width of the screen (which it previously did not do on 4K displays) but the function call navigation and file navigation sidebars are annoying. I understand the usage of the sidebar navigation but I wish that explicitly dismissing it would keep it hidden and not reopen it when I click, highlight, or navigate in the code. Much like @R0rt1z2, this is mostly personal preference, some of which I fixed with greasemonkey scripts but I still feel the behavior is incorrect.

I also agree with the comment box width problem. For a long time, GitHub had used explicit pixel widths for many elements instead of using relative spacing and this made viewing on 4K or higher resolution displays quite annoying.

[willsmythe]

Another (very) annoying issue I’ve noticed is that the indentation appears to be broken in some cases. See this commit for example.

Thanks for the feedback. We're looking into it.

[willsmythe]

Another (very) annoying issue I’ve noticed is that the indentation appears to be broken in some cases. See this commit for example.

@R0rt1z2 - we rolled out a fix for indentation issues on some browsers. Can you see if it resolves your issue with viewing this commit?

[R0rt1z2]

@R0rt1z2 - we rolled out a fix for indentation issues on some browsers. Can you see if it resolves your issue with viewing this commit?

@willsmythe It seems to be working fine now. I tried with that commit, and the indentation looks correct. I'm using Firefox on Windows.

[jrbyrnes]

... I can't right click to copy/paste the code?

[mfn]

aha – I guess then it doesn't work because, when I right-click, my selection is cleared.

Noticed this too; selection should (also) stay.

[smuuf]

When it works, it should copy any currently selected text (if any) otherwise it will copy the selected line.

How about just not hijacking the native right-click behavior?

[Metanesia]

This public discutions can i commented too?

[homira135]

بنده روببخشیدعذرمیخوام ولی خداوکیلی ازی طرف ازتحتساب بازیهامون کم میشه ازی طرف اینجاتقسبم حذف میشه

[ForLoveOfCats]

The new design seems to struggle with tab indentation in files. For the sake of completeness I'll mention that the below screenshots are using 4-space tabs in my user settings but the effect in the new design is the same with the default of 8.

Old:

New:

[yugecin]

seems like it's just "swallowing" the first tab, and even more because the first letter is cut off

old:

[sfan5]

I saw just the new commit page for the first time today and it's not understandable to me how Github has not stopped the beta rollout when there's such an obvious bug.
Fortunately I can just opt-out.

[AdamShwert]

What browser/OS are you all on, and do you have any plugins for GitHub installed?

[sfan5]

Firefox on Linux (X11). No plugins or CSS modifications for GH.

[sersorrel]

The default-collapsed commit text seems to utterly miss the point of the commit details page. It's also much harder to read – the previous page used #1f2328 on #f1f8ff, which has an excellent contrast of Lc 98.0, but the new page uses #59636e on #fff which works out to only Lc 80.5, which is well below the preliminary APCA Bronze threshold of Lc 90. In conjunction with the smaller font size (was 13px, now 12px), the commit text is now very difficult for me to read.

Duplicating the first line of the commit text (once in the big heading, once in the monospace body) seems a bit odd:

Lastly, the line-height of the code is uncomfortably large, I really hope you don't intend to use this style across the whole website going forwards.

[alphapapa]

Ugh, thanks for pointing out the contrast change. Haven't we learned that light-gray-text-on-white is an anti-pattern by now?

[legoktm]

I agree, the commit message is much harder to read because of the light gray and shouldn't be collapsed. I don't understand why it feels like there's an aim to de-emphasize the commit message, it's often more important than the code itself!

[willsmythe]

A fix for the text color problem has rolled out. You should also now see the full commit message. 🎉

[apripista]

Great

[sersorrel]

When you start writing a comment, the textbox now expands off-screen:

so you have to scroll down again to see the button to submit the comment now. If the comment box were not collapsed by default, this would be solved. The page also doesn't seem to have the standard GitHub footer, which doesn't help.

On wide screens (and by "wide" I mean "16:9 1440p"), having to mouse all the way over to the right-hand side to add a comment makes it really hard to see which line you're commenting on (unless you want to open the dialog, check the line number on the right (which says "R" for some reason?), pull your eyes back to the left-hand side to check the line number there, and try again if you aimed wrong):

And the tooltips on the comment widget buttons ("Heading", "Bold", etc.) appear to have been dropped, which sucks.

[willsmythe]

Thanks for reporting. The team is working on a fix.

[adlai]

Clicking on the line number first boxes that line, and makes it easier to aim when going to the opposite side of the diff listing.

[adapap]

Links to diffs for specific ranges no longer work. The page does not correctly focus the view on the range present in the URL (for example, the URL ending with #diff-<sha>R<000>-R<111>.

[SaaSCh]

function validateEmail(email) {
  const regex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
  return regex.test(email);
}

// Example usage:
console.log(validateEmail("[email protected]")); // true
console.log(validateEmail("invalid-email")); // false

This JavaScript function validateEmail uses a regular expression to check if a given email address is valid. The regex pattern ensures that the email address follows the standard format of [email protected].

[RENSAAS]

function validateEmail(email) {
const regex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$/;
return regex.test(email);
}

// Example usage:
console.log(validateEmail("[email protected]")); // true
console.log(validateEmail("invalid-email")); // true

[cynecx]

I am a heavy mobile user and I need to review code on the go...

There is so much wasted horizontal space and the wrapping makes things even worse. This makes reading code unbearable... I'd almost say impossible. I've been using a userscript before the new design that made a few css adjustments but seeing that this isn't possible anymore makes this even more frustrating.

[cynecx]

One solution for this is to just stop wrapping things. It makes stuff so harder to read on width constrained devices. Or at least let the user toggle the wrapping behavior.

[cynecx]

Also the spacing/heights of the file header is just way too big. Again, on mobile this is way worse than desktop.

[willsmythe]

Or at least let the user toggle the wrapping behavior.

Thanks for the feedback. We are exploring adding a user setting, similar to the "wrap lines" setting we have when viewing a file.

[KNYNE88YAKIMAWA]

Wi are getting FUKED

[ayylmaobackup]

Some code can be borderline unreadable on mobile

[jakub-cernik]

Same, this happens on desktop too. I should be able to scroll to see the whole line. Line wrap is not useful here.

[willsmythe]

Thanks for the feedback. We are working on a fix for tab/indent behavior, and also exploring adding a user setting to toggle line wrapping.

[AdamShwert]

This should be resolved - are you all still seeing the problem?

[Rockyspade]

fixed <tab/indent> beta 3.0 update status

[kemeryrugiet]

Nice app,

According to your readme, it says you have an unsigned macOS executable "Download executable for macOS platform from latest release, see assets" . . . but I could not find it in the assets.

[b264]

Not having a "Show all hidden content" button pretty much makes this commit view page UNTRUSTABLE.

Like, I am seeing some sort of overview of the commit? I want to see every change, period. I don't want to rely on whatever algorithm you're using to hide stuff from me when I might be looking for a bug. Not having this button almost means the entire Github platform is now unusable if I can't even look at a commit anymore. The whole commit.

[esacteksab]

I don't like the file browser. I often want more than one file open at a time and too many times I go to right-click a file and I can't. Then I have go scroll to the top, click the repo's title, and sleuth through the code. Or open a duplicate tab. Both are more work than I want to do and/or would expect to be able to do with being able to right-click -> Open in New Tab. Just my $.02 cents.

[rmottola]

The latest update seems to introduce a lot of CR/LF which are not visible, but noticeable on copy paste when in diff mode. It shows the sam

If a section of code is then copy-pasted two new lines are inserted after every line. This is a new regression. The previous release conversely did "chew" empty lines, before that though it used to work and outside the beta it works fine too. So definitely an issue.

[jonrajavuori-academia]

This isn't a new issue at all, rather one that's been around for years, but I've confirmed it remains an issue on the preview. If you're taking feedback on the page, I'll take the chance:

Your diff views slow to a crawl, sometimes becoming completely unusable, for very large diffs (5000+ files with a dozen or so changes each), even in Chrome on a powerful desktop PC. It seems like you've run into this problem in the past and attempted to fix it by simply putting a hard cap on how many files the page will ever attempt to display. However, I'm pretty sure that since you've continued to add features to the page, it has slowed down enough that that hard cap is no longer sufficient.

Rather than cap the number of files displayed at all (which is horrible in its own right), you should make a serious effort to optimize the page's rendering correctly so that it doesn't attempt to render file diffs that are not in view at all. This isn't trivial but it's an essential optimization for any web application handling huge amounts of data like this, and honestly it's very surprising you haven't managed it yet (or managed it correctly at least).

[kemeryrugiet]

I think what you're suggesting is a good idea, but only if the diff is abnormally large. For normal-sized diffs it's nice to be able to scroll up and down without having to wait for lazy loading

[rocifier]

Hi. I cant find any review button on mobile. I'm using a Samsung Galaxy S21FE and lots of things on this new layout bleed off the screen or look jumbled

[Blessingudeme]

Why if I want to make use of my account or to receive ton key I can receive what is going on

[Meerkat456]

Hello, I was working on the readability assignment and it counted all my answers wrong because I put 'Grade:' instead of 'Grade'. Is it only going to be checked by a bot?

[sk7salman]

Hi
I am not able to find KOSOVO country flag,
I found ekwonye-richard/react-flags-select@37e9538
in which its added I need to know when this will be deployed and new version of react-flags-select ie 2.2.3 will be put which will include KOSOVO country in the flag list?

[chong1218]

👍