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.

[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

[chandler-cloud]

I wanna some engineer to help me achieve my goal

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

[Wesnei]

Concordo, realmente esses pontos que você citou é verídico.

[pckotzer]

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

[Reunt]

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

[Spiderouf]

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

[1AyaNabil1]

Great Job

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

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

[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

[tomsepe]

It would be nice if there could be precise timestamps on the commits reported on the website. right now the page will just say "committed last week" This is true at the main page of a repo and also if I select a file. Only if I click on the little clock icon can I get a little more detail of listing commits by DAY, but it does not show the times.

Why does this matter? It would be useful for time tracking, to know that I or someone else was working on a file.

[RobertKrawitz]

xref https://github.com/orgs/community/discussions/5972
xref https://github.com/orgs/community/discussions/16550

[rgaricano]

Commit 802f880 open-webui/open-webui@802f880#r153245052 is incomplete, on src/lib/components/chat/Messages/Markdown/MarkdownTokens.svelte line 94 'e' has to be changed by 'value',

now code content is not saved when change/save, changing it works.

[pdewilde]

I find the UI to be very misleading for how it displays tags/versions.

actions/cache@13aacd8

The UI shows a tag icon with 4.2.2 which would make one assume this commit is tagged at that version, but it actually is a year before that tag.

[F5beep]

اريد استيراد

[rmacklin]

I've opted out of the new experience for now. Upon doing so I was prompted to give feedback in this discussion, so here goes:

This message:

Some content is hidden
Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

implies that the browser's native "Find in page" functionality is broken - and indeed it does appear that some search results are not discovered by the native "Find in page" until they are scrolled into view.

When the new code view was developed, the broken "Find in page" functionality was the most common critique of it, and fortunately so many people voiced this that eventually it was fixed. Do we need to rehash those arguments? Or can we agree that we should not take a commonly used page which had a fully functional "Find in page" and reimplement it in a way that breaks the browser's native "Find in page" feature?

TLDR: Please remember there are many valid reasons to use the browser's built-in search feature - and please avoid breaking that functionality. Thank you for reading!

[tonycoz]

Is there a way to turn this hiding off?

(this is from comments on a line in a commit, the comments used to be shown inline like they are with PR code comments)

[Ahmedsalah1989]

I'm surprised how regular users use the API ,
or do you misunderstand your application in this point?

[darikprescott]

What do you mean

[josev94]

It would be nice to be able to see the UTC Timestamp of a commit somewhere more visible. "Merged x weeks/hours ago" isn't particularly informative.

[cheyannemiller1]

I was coming here to say the same thing. I'm looking for an exact date not "last month". Last month is not a helpful window when looking for a regression's time window of impact.

[Fluffy728]

Please don’t promote any of your browser extensions, @Alex-302

[RobertKrawitz]

xref https://github.com/orgs/community/discussions/5972
xref https://github.com/orgs/community/discussions/16550

[smuuf]

New (beta)	Old (current)

I don't think having the commit's title (first line of its message) de-emphasized is somehow a better UX than as it was before. Let's keep the commit's title properly distinguishable, please.

[Fluffy728]

+1

[Fluffy728]

I need a way to revert files easily!

[ket395]

I need it to but currently the workaround is to download and install GitHub Desktop. It provides a GUI to easily to do so. Just download, verify download, install, test install, clone a remote repo or add a local repo, go to History tab. Select any commit and the last line of the first third of the menu will show the option.

Though sometimes you will certainly run into a merge conflict. For which you need to manually undo each of the conflicting files one by one if you use the GUI. I recommend trying the git or gh CLI for this.

Happy to help.
Manish

[xremming]

When linking to a line in a file which has its diff automatically collapsed, navigating to the link should uncollapse the collapsed file.

Now when you open such a link it just goes to that file's location and you need to manually click the "load diff" but even after that the page is not scrolled to the correct position.

[Fluffy728]

+1!

[ket395]

If the URL includes the state as collapsed then it must always be collapsed when the link is accessed by any user that has access rights to the repo.

And vice versa for the opposite case.

If the URL does not include the state as collapsed then there is no expected behavior that can be agreed upon. Choosing anything will produce dissatisfaction from the users that have a different or opposite preference for the expected UI behavior. Adding ancillary state to remedy this using any other means would raise clear privacy violation flags for every user and potential for abuse by malicious actors. Since that would involve storing that data and it's complementary software (client side and/or server side). More often than not people do not make informed decisions and that can cause issues with GitHub usage. For example - creating a public repository for a project that must be private, create a public repository for a confidential project then making it private once automation is tested, committing confidential secrets to a public repository, using informal language in a public repository, over aggressive or excessively coarse/fine or outdated content screening settings etc. You can trivially verify these and more by a cursory glance at public snafus on Github Gitlab BitBucket and Gitea Gogs and others.

Happy to help avoid unintended avoidable disaster or disasters?
Manish, check out my kind of oldfangled, kinda newfangled, kinda cool, inevitably thought-provoking profile.

[kaihendry]

Can't see a timestamp. "committed 14 hours ago" is not good enough.