<story><title>Ask HN: Thoughts on new GitHub layout?</title><text>I think it feels like Jira and I&amp;#x27;m really sad. Seems more like a MS move than a GH move...&lt;p&gt;Migrating to gitlab...</text></story><parent_chain><item><author>ljm</author><text>I submitted feedback over it but, aside from the over-reliance on rounded corners, and making pills and buttons hard to separate, the single worst change is that you can&amp;#x27;t see the latest commit status from the repo screen. Instead, you get the commit hash, and have to click a tiny ellipsis button to get the commit message and the status indicator.&lt;p&gt;When I&amp;#x27;m browsing on github and not using git directly, the commit short-hash is the last thing I care about. You cannot see if your default branch has passed CI&amp;#x2F;status checks now. Those things should be first class citizens, that&amp;#x27;s why we put status badges all at the top of our readmes to make that info more visible with what we have.&lt;p&gt;It follows the trend of designing with lower information density. This trend IMO is not appropriate for developer tools.</text></item></parent_chain><comment><author>natfriedman</author><text>Thanks for the feedback about the latest commit status. This is something we should definitely fix.&lt;p&gt;Also – I don&amp;#x27;t think there is a principle of lowering information density at work here. I think it&amp;#x27;s just a design that we will keep iterating. We are pro information density at GitHub.</text></comment>
<story><title>Ask HN: Thoughts on new GitHub layout?</title><text>I think it feels like Jira and I&amp;#x27;m really sad. Seems more like a MS move than a GH move...&lt;p&gt;Migrating to gitlab...</text></story><parent_chain><item><author>ljm</author><text>I submitted feedback over it but, aside from the over-reliance on rounded corners, and making pills and buttons hard to separate, the single worst change is that you can&amp;#x27;t see the latest commit status from the repo screen. Instead, you get the commit hash, and have to click a tiny ellipsis button to get the commit message and the status indicator.&lt;p&gt;When I&amp;#x27;m browsing on github and not using git directly, the commit short-hash is the last thing I care about. You cannot see if your default branch has passed CI&amp;#x2F;status checks now. Those things should be first class citizens, that&amp;#x27;s why we put status badges all at the top of our readmes to make that info more visible with what we have.&lt;p&gt;It follows the trend of designing with lower information density. This trend IMO is not appropriate for developer tools.</text></item></parent_chain><comment><author>JoshTriplett</author><text>&amp;gt; the single worst change is that you can&amp;#x27;t see the latest commit status from the repo screen. Instead, you get the commit hash, and have to click a tiny ellipsis button to get the commit message and the status indicator.&lt;p&gt;Omitting the commit message is a net improvement to me; I&amp;#x27;ve found that the commit message of the random commit that happens to be at top of tree is completely unhelpful for someone browsing the repository, and especially someone new to the project.&lt;p&gt;However, showing the status indicator inline does indeed seem like a good idea.&lt;p&gt;That said...&lt;p&gt;&amp;gt; You cannot see if your default branch has passed CI&amp;#x2F;status checks now.&lt;p&gt;If it hasn&amp;#x27;t passed CI and status checks, it shouldn&amp;#x27;t be in your default branch.&lt;p&gt;(There are cases where periodic status checks may get re-run after merging, such as checking if your default branch builds with more recent versions of software than it was originally tested with. But the normal CI and status checks should run &lt;i&gt;before&lt;/i&gt; merging.)</text></comment>