Oh that’s super annoying. We use that to draw attention to important things that changed in certain commits, for instance we attach human readable diffs to lock file change commits.
Beyond that sometimes it’s super helpful to add comments as a human directly to a commit noting details about that specific change set that don’t make sense in the commit itself.
This is one of the most boneheaded moves I have seen GitHub make.
It does seem very strange. If I'm looking at a PR, especially a historical one which has been merged already, I want to see all the comments which were made about the commit in one place.
If it was confusing to have these comments turn up "out of context" then maybe that's something that github could have improved instead, by visualising the context better.
They seem to be removing heavy features from often-used pages. I would imagine this change creates quadratic savings in data fetching for the timeline.
Honestly, if that was the reason ("we need to make our mysql faster"), I would strongly prefer if they'd just say that. Certainly more understandable (if not relatable) than this sort of communication.
They've been in a roll nerfing stuff like this ever since MS bought them. See "load more comments" ajax links when there are more than 10 comments in a PR review, or "load diff" when a file has changed more than a few lines. All of these degrade the ability to actually look at changes and review them, which is kind of the whole point of pull requests. But alas, the enterprise must enterprise.
This could be so, but wouldn't a better solution be to prerender popular pages or cache generated HTML (a la memcached etc)? (Having said that I have no idea how modern web apps work, nor what technology stack github is using.)
Caching what? All possible comments everywhere? That’s just another db, not a cache. And having infinite caches is not feasible, the point is to store widely and frequently accessed data, not anyone’s comments on any commit in the repo.
I see I wasn’t the only one to conflate “commit comment” with “commit message.” For a good 5 minutes I thought this was saying that GitHub would no longer show commit message content in the pull request timeline, which does seem like a crazy vendor lock-in scheme.
When you view a commit on GitHub, you can attach a comment to any given line of it. It looks basically like a comment left on a line of code in a PR, except tied to a commit instead of a PR.
A comment <-> PR is a many-many relationship. For a lot of workflows it's practically a one-to-one, as people would only comment on a commit starting from a PR, but you can just comment on any given commit you find.
That wasn't part of a PR (GitHub didn't even exist then), and if it was it could be a part of many different PRs.
I really don't have a full overview of this GitHub change, but this general area is something other hosting providers have definitely struggled with.
I.e. how and when to treat a PR/MR as some holistic vertical component, v.s. being mostly incidental metadata about a "push" (or "potential push"), with the commits (and any comments) being the important way to view or think about individual changes, and anything in-between.
You can still add comments to an individual commit and view them from various pages. However, comments added this way will no longer surface in the timeline(s) of pull request(s) that happen to include the commit. This does not change anything about pull request review comments, including review comments added when reviewing a pull request commit-by-commit.
Beyond that sometimes it’s super helpful to add comments as a human directly to a commit noting details about that specific change set that don’t make sense in the commit itself.
This is one of the most boneheaded moves I have seen GitHub make.