Show the contents of the latest Commit's message on the "home screen"

[d4mation]

Before the UI update you could see at least part of the latest Commit's message without having to click that little button to expand it.

Reverting to that old behavior would be nice. It can be helpful to, at a glance, see what the latest change was related to.

New UI:

Old UI:

https://web.archive.org/web/20191212174936/https://github.com/microsoft/vscode

[d4mation]

The above "Old UI" example was for a merged PR which may not be especially exemplary of what it was like. Here's one that did not require the button at all to expand it.

https://web.archive.org/web/20191108090934/https://github.com/Microsoft/vscode/

[daattali]

Yes that's certainly something I really miss too. I think not showing the last commit message is a really bad decision but github. But unfortunately this can't be achieved with this extension, see the Limitations section in the README. I did look into this a few days ago but it can't be done properly

[d4mation]

Could .Details-content--hidden just be given display: block !important!;?

While not perfect, it would force that area to always be expanded.

[zekefarwell]

If you look at the blue bar closely, in the old design it was fully dedicated to the latest commit so there was plenty of room for all the information. In the new design they've added links to the commit history, tags, and links or the right hand side. So to make the first line of the commit message show up the way it used to would require moving those elements – more layout shifting than this extension is trying to do.

Just expanding the .Details-content--hidden as you propose is not a great solution because then the full commit message will always be shown even if it is many lines and that wasn't how it was before.

[daattali]

Making it show is possible but then it wouldn't be hide-able. I don't want to fix one thing in order to break another. As much as I hate this decision by github, I'm going to have to live with it.

You can use a javascript extension to run a one liner on large load that will make it visible initially by removing a CSS class from it, but note that if you reach the Code page after already being on some other page on github then that script won't run. It will only work if you type the repo URL into the search bar.

[daattali]

See this comment https://github.com/daattali/oldschool-github-extension/issues/7#issuecomment-649791792 if you want to try to implement this yourself using javascript.

[chocolateboy]

note that if you reach the Code page after already being on some other page on github then that script won't run. It will only work if you type the repo URL into the search bar.

FYI: there's no reason why it shouldn't run. I'm happy with (and prefer this to be) a CSS-only solution, but making content/user scripts work in SPAs is neither "buggy and very difficult" to get working correctly nor "non performant":

• GitHub
• Twitter

[daattali]

That's a very handy script for showing first commit - I'm using that now :)

@chocolateboy how does that work without a mutationobserver? Where does $.onCreate come from - I couldn't find any documentation for the onCreate function, I dont' fully understand how this all works

[daattali]

Ah I finally see, you're importing that function from https://github.com/eclecto/jQuery-onMutate - which is using a mutationobserver.

I suppose I always try to steer away from mutation observers but you're probably right that it won't actually have any practical impact in a small page like github.

In that case, this is indeed worth pursuing

[zekefarwell]

I think it's a great goal to do as much as we can with CSS. But for things that truly can't be done with CSS, I think exploring a minimal JS solution is worthwhile.

[chocolateboy]

That's a very handy script for showing first commit - I'm using that now :)

Thanks!

Ah I finally see, you're importing that function from https://github.com/eclecto/jQuery-onMutate - which is using a mutationobserver.

Yes, it uses a MutationObserver wrapper.

The point is there's nothing complicated, slow, or "hacky" about waiting until an element appears on a page and modifying it in a content/user script. Quite the opposite: trying to do things statically is flaky/buggy precisely because it doesn't match the dynamic nature of the page.

There should be no performance issues with MutationObservers, regardless of the page size (or if there are, you've found a browser bug). Perhaps you're confusing them with the old, deprecated API (Mutation Events)?

[chocolateboy]

And just to re-iterate (my 2c): I prefer this CSS-only approach (amongst other things it means I don't have to audit the addon :-)), and wasn't requesting a (partial) move to JS. While I'm not a fan of the sidebar, I've got used to it (and I like seeing the languages without clicking).

[daattali]

Seeing the languages without clicking is nice, and that's how the WIP PR has it https://github.com/daattali/oldschool-github-extension/pull/26

I have seen mutationobservers (the new version) cause large dynamic pages to have horrible performance - but it was in cases where there really was a ton of dynamic elements being created and updated all the time. In this case it wouldn't apply.

[chocolateboy]

have seen mutationobservers (the new version) cause large dynamic pages to have horrible performance

That definitely sounds like a bug. I have userscripts that work on Google Images and Twitter (on which a ton of dynamic elements are created and updated all the time), in Chrome and Firefox, which never have any performance issues.

[daattali]

@chocolateboy would you have the time to contribute a PR that adds the minimal javascript required to get this to work? Ideally without having to import the external JS lib?

[chocolateboy]

I don't want it to work :-) (IMO, this particular feature would be better implemented by a userscript or an addon like Refined GitHub).

I'd prefer this to remain pure CSS (i.e. a userstyle) unless there's a plan to revert and significantly improve on the sidebar that needs JS (I'd like to be able to access releases from any page again rather than just the main page).

I was just pointing out that it can work...

[chocolateboy]

FYI: https://github.com/sindresorhus/refined-github/issues/3277

[daattali]

Thanks for your input. I was thinking that if a little bit of javasript creeped its way into here, then fixing the commit message on page load and moving the sidebar would be the two benefits of it.

[kidonng]

https://github.com/sindresorhus/refined-github/pull/3278#issuecomment-649488947

[daattali]

@kidonng correct me if I'm wrong but that seems to be a solution to a different problem - to showing the entire message instead of only the first line. The issue at hand here is for showing the commit message when the page loads , I don't think that can be done with CSS

[kidonng]

@daattali It's exactly the first line of the commit message (and no description) because of height: 1.5em.

showing the commit message when the page loads

Sorry, I don't think I understand what you mean. Applying the style will make the first line of the commit message always show (not affected by the toggle, that's the only "issue" I've found).

[daattali]

That's what I meant - for any commit message that is under 50 characters, the toggle button becomes broken - it doesn't do anything. I really like seeing the first commit message but I don't want to break any functionality with the changes we make.

[zekefarwell]

Looks like this issue may not need to be resolved by old school github. A new feature preview just showed up for me called Latest commit design updates. It appears github has listened to user feedback and made some adjustments in this area.

Try out an updated design for the latest commit on the repo homepage, based on community feedback. This version keeps the first line of the commit message visible on desktop screen sizes, and moves branch and tag links next to the branch select menu.

Feature preview enabled

Feature preview disabled

[blcarson]

Good start but they need to do the same for the sidebar - that's the most jarring change for me.

[daattali]

I saw that too - it's nice that they are considering reverting this> Hopefully they'll follow suit on the sidebar, though I doubt that

[daattali]

Closing since GitHub (at least for now) added it back :)