Commit comments no longer appear in the pull request timeline
github.blog
github.blog
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.
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.
If they're inside of PRs are they still commit comments? I'm thinking not, in which case maybe I never noticed those were a possibility.
E.g. here's git.git's first commit, with a lot of random (mostly garbage) comments: https://github.com/git/git/commit/e83c5163316
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.
No name for blog post author.
No gradual rollout I think? Was this ever a beta feature first like most other things?
Compare to Stripe product releases where people who built it are instantly on HN, responding to feedback.
Is there someone at GH who actually owns the PR experience and sets the long term roadmap for non-enterprise?
Although, it doesn't seem to recognize my extensions, even though it automatically logged me into my VS Code account via GitHub's account (which is how I normally do it).
you shouldn't be
As a result, we went back to the drawing board and rewrote the changelog from scratch to try and increase clarity: https://github.blog/changelog/2022-08-04-commit-comments-no-...
Does this help? We hope you'll accept our pull request. ;-)
And yes! We have engineering, product, and design leads supporting the PR experience who are super interested in getting your collective feedback about where we should take the experience next.
This was posted in the changelog section of our blog, where posts aren’t attributed.
Our roadmap, including PR improvements and features is here: https://github.com/orgs/github/projects/4247/views/1
We need the feedback loop and the historical setting for why we made this decision two years ago. Until or unless we treat requirements as first class citizens in our source code, archeological digs are the last best hope for avoiding reintroducing old bugs.
I also need to be able to go back and disagree with something I or someone else said as an absolute in a commit message that turned out not to be an absolute. That stuff trips up the new people. It’s the worst kind of tribal knowledge.
I do find the homepage very complete and the documentation very understandable though, would recomend taking a look if you're interested.
Git can store a variety of other objects in the repo as well, but the built in git-notes mechanism springs most immediately to my mind as the thing you’re looking for.
Actually I think that lots of things that's currently located outside of the repo should be in the repo. Like issues: just put them into some `issues` directory with some standard format and build UI around it.
Do you mean attaching a mailing list to git or a feature for syncing comments to commit ids? If the former, you think sending a new guy to read four years of yammering about code is a useful or non hostile suggestion? It’s okay to be a misanthrope, as long as you understand that about yourself and when it colors your interactions.
But this is how this conversation usually goes:
There are any number of addons and special hidden features of git. If they don’t propagate to and from developer machines without proper user configuration, it’s a checkbox feature, not a real one. And the worst kind - the ones where people can dismiss a real and near universal problem by saying “we have X at home”.
Half of the good features of version control, CI/CD, you name it, are good in part because they only require one or two people to put in the effort and then everyone benefits, whether they recognize the value in it immediately, over time, or leave the team insisting it never helped them once even though other people know that’s not true.
Any feature that requires everyone to set it up on their box requires unanimous decision. That doesn’t scale, and it barely works on a small fixed team either.
Most of the tools I see people claim git has involve changing the configs or your behavior in order to sync the extra metadata. Do it by default or don’t do it at all. This is you being wishy washy and letting someone else take the blame for it not being used.
Edit: are you talking about ‘git am?’ That has nothing at all to do with what I’m talking about and also is only used on non commercial products. The only people I know of who use this at work are professional OSS committers who aren’t working on projects hosted on GitHub. Which is zero people actually in my professional circle, and if those people know anyone they haven’t mentioned it where I’ve heard it.
You can argue about the utility and practicality of GitHub, and the tools provided by the platform, however Git is neither is an invention of GitHub nor have a monopoly over it.
Lastly, having no clue about a technology as a professional developer has nothing to do with the utility or usefulness of the feature. On the contrary, a professional developer should be able to work in a much more flexible and open-minded manner about different working methods and workflows.
All in all, the mailing list can act as an internal time-based knowledge base which can store both the code review and decisions coming out of it. The decision to use it or not of course yours and your team's, but send-email and am are not features confined to "professional OSS committers who aren't working on projects hosted on GitHub" by any means technical and social.
Also, you can like the feature or not, and may decide against it just on personal preferences. However, this neither moves the feature to a niche place, or makes it obsolete.
I follow a few of the Linux kernel mailing lists and frankly I am jealous af; no Slack, no Jira, no web UI I can accidentally refresh which flushes state and deletes the comment I was writing. Was less bandwidth hungry.
Hosted UI just seem like a huge waste and a whole lot of agency capture by VCs. Just release a Docker image, give me an API key.
You, sir, have been caught. At the time of this writing there is only 1 other comment.
"drey08 38 minutes ago | unvote | parent | next [–]
This is about commit comments, not commit messages."
I put a lot of effort into commit messages and try to always give a good summary of what (and more importantly why) the change was made. I consider it almost as important as the code itself, because it serves as a form of documentation, as well as a way of communicating to both other team members and my future self.
I struggle immensely with writing normal documentation, whether it be fine-grained stuff like descriptions of functions/classes, or higher-level architectural issues (I have written a PhD thesis so I can do it, it's just a tremendously difficult undertaking). I treat commit messages like a second best alternative to code documentation, and they're a lot easier to write because all the information is fresh in my head at the time I make a commit. A good log can also serve as a solid starting point for later writing other forms of documentation.
Git is designed as a decentralised version control system; pull requests are something that the major repository hosting providers have added, and while I appreciate the existence of those features I'd rather not rely on them at least in terms of the long-term record for a project. In the case of pull requests, someone who is already writing detailed commit messages basically has double the work if they want to communicate the same kind of information in pull request descriptions/comments, though you can just make the comments a copy of the log (BitBucket does this). And if you want to migrate from one provider to another you can lose all this extra context that is not in the repository itself.
Other than attempt to increase lock-in, I don't understand why they would make this change, and it seems like it's based on assumptions about how some teams use git without taking into account other styles - there's considerable variety in practices between teams and for those that rely on the commit messages more heavily this seems like it's going to make for a worse experience.
This was definitely not obvious to me from their announcement and I wouldn't be surprised if others similarly misinterpret it.
> Note: This change does not impact regular review comments or other comments made directly on a pull request.
Root cause? I didn't even know commit comments were a thing that GitHub had! I assume it was much clearer to everyone that knew about them.
Me too. It wasn't a term or feature I was familiar with, and (incorrectly) assumed they were talking about commit messages.
Anytime Ive done code archaeology, the commit messages, no matter how detailed, have been irrelevant to what's currently running.
Between reading a book of commit comments, or the authoritative code, it's much more efficient to just read the code.
One of the big things with commit messages is that they won't capture changes in adjacent systems that don't share a code base. While you can spot weird edge cases in the code, you can't from the commit messages alone
The point is to capture what is true at the time the commit is made, and in aggregate to tell a story of the code's evolution. If someone wants to know why a particular thing is done the way it is, then this can provide insights as to how it got that way and why.
I don't regard a commit log as an adequate substitute for documentation on the latest version of a codebase. Rather, it can provide a useful starting point for writing documentation that I find easier than beginning from a "blank page" so to speak. It's a starting point only - there's a lot of work required to get from that point to an accurate description of the most recent version of a codebase.
I agree with your point about changes in adjacent systems, though where that happens I try to mention those changes in the commit message and explain how they relate to the commit itself. I'm speaking mostly from experience working on software that exists in a single repository; for things that are split among multiple independent repositories/services I agree it's more difficult (and this is why i prefer monorepos whenever its viable).
I hope GH fixes the notification link to PR updates. Right now it brings you to the latest commit, and if you comment on that page, it creates a commit comment instead of a PR review.
Currently, you can only pick two of the following three things, which pretty much everyone wants. People have been asking for the above feature for 5-10 years.
- leave a pointer to the code review in the git commit log
- have a linear, bisectable history
- preserve developers' commit messages and intermediate work on branches
There are different types of comments in GitHub, and ironically, this change was made to reduce confusion by not surfacing comments made on individual commits (comments added from the commit page on GitHub) in the timeline(s) of pull request(s) that happen to include those commits.
Nothing has changed for "pull request review comments" (comments added from the pull request page, including comments added when reviewing a pull request commit-by-commit). Also, nothing has changed in the way GitHub surfaces commits or commit messages in the pull request (or any other) page.
Hope this clarifies. If not, let us know.
Gitlab allows you to comment any line in the code even if it's not part of a MR now. In theory I find that highly useful, because you might have thoughts, findings etc. whenever looking at code, not only in a MR.
However, I have not found a way to discover any such comments later in a systematic way.
Certainly almost every comment on hacker news hasn't understood the change
You can make comments directly on commit objects in GitHub, almost nobody ever does this. You used to see these comments appear PRs (but couldn't reply or resolve them) but now you don't. Nothing has changed with actual PR comments, or code comments, or anything that most people actually use
Parent commenter and several others said they found it very valuable. People seem to want this. Feels like enough of a reason to not remove it for all users with no heads up.
The use case I do see sometimes is having a pull request made up of distinct commits which are each commented on, but that's already a bit of a poor UX in GitHub, easily worked around, and is pretty uncommon.
I mean what is your suggestion to OP? Putting their head in the sand and acting like Github didn't remove a feature they in fact had removed? It's a very niche feature (so much so that more comments seem to misunderstand the feature than actually miss the feature) so the chance of Github not removing it is fairly low even if complaining causes them to delay it a bit.