▲ 153 points
back
85 comments
Information that can be automatically extracted from the delta is the least important part of a good commit message. I can figure that part out from looking at the commit later. Instead, what I really want to know is why you made the change. What is the context? What problem were you solving? Why this way and not other ways you might have solved the problem?
A summary of what the change does is still useful, and I'm glad this can now be automated, but it's not the main benefit of a well written commit message.
Came here to make the same comment.
There is a great blog post about it: https://dev.to/jacobherrington/how-to-write-useful-commit-me...
It boils down to the following commit message template:
<what you changed>
because <why it was needed>Design decisions should really go into docs rather than commits.
Out of three (commits, comments, docs), the commits are least approachable, just few changes in the code will erase original commit in the blame.
By all means write good commit messages, but crystallize the info in them into changelog or other docs every bigger release
From my experience people rarely read the commit message s, so it is better to put the why part into comments in the code, not git history. I mostly write the detailed why part in the commit only for refactoring changes.
I like to put the why first. Makes it easier to follow.
Was looking at the examples (link posted at another comment) and this addon seems like a good starting point for an accurate commit message.
Starting point. After that it should up to the committer to make modifications and upstream the message. For those cases, seems good enough for me.
Haven't tried this solution but my first thought was of those (.NET) libraries that would generate comments using a functions signature (function name, parameter name, etc.). Remember some senior devs at the company I worked for at the time being mesmerize and overusing this. We ended up with comments that could easily be inferred from reading the signature...
I like those in general because you can hover over a function call in visual studio to see a description.
A summary can still help you remember the parts of what you did and more accurately fill in the why.
I think you would be surprised how PRs work in many companies. We are encouraged to write small PRs and many will have automated tools that points to a Jira ticket in the description or as a comment. For this reason many leave empty descriptions. In such cases this would still help.
I disagree. Unless there’s some smarter way to do this, I use the commit messages to find the kinds of historical changes I’m curious about. I want to know what changed. I’m not sure how one would do this unless they’re looking at every commit.
The “why” goes into the PR and more importantly, engineering documentation and inline comments.
Plus, a commit message seems woefully plain and too short to properly communicate these things.
The beauty is that this isn’t prescribed. We can all do what makes sense for our contexts.
> The “why” goes into the PR …
This just ensures that the “why” is lost when someone comes looking years later.
From experience, SCM history is far more durable than just about any other work product we produce.
Over five decades later, commit history was still available for the Unix sources and could be reconstructed: https://github.com/dspinellis/unix-history-repo
I’ve used 35-year-old commit messages to help understand a long-standing issue, decades after all other related organization tooling and data had disappeared.
What I have always been told for writing good commit messages is that the message should tell you what the commit does when applied to the code. The place for these what/why messages would appear to be in a ticketing system of some kind, referenced by ID in the commit message.
What you're asking for would result in extremely bloated messages.
On my tests the GPT3 is able to understand the whole context and give a very good commit message.
This commit sets the value of variable x to 10 on line 253 of the file main.go
> Are you a software engineer looking for ways to make your workflow more efficient, or tired of manually sifting through long commit logs to understand pull requests? Introducing the GPT summarizer GitHub action: a powerful tool that leverages OpenAI’s latest and greatest large language model to generate concise and informative summaries of the entire pull request, as well as descriptions of the changes to individual files and individual commits.
This kind of stupid.
1. At best, all this can do is look at what you actually committed, but that's not going to tell you the most useful stuff that should be included in a commit message, like why you're making the change in the first place and what your intent was (which may deviate from what you actually did).
2. If you wrote the damn commits, you should be able to describe them yourself. If you can't, something's wrong.
The only case where I can see a tool like this being useful, instead of a bad habit, is summarizing old commits, where the committer didn't put anything useful in the commit message.
"Let GPT write the description, so you can focus on the explanation" would be better
It isn’t stupid if it works. If this allows an engineer to spend 15 mins less time while generating good enough PR descriptions, that’s a huge win, especially if the developer isn’t a native English speaker. IME people after getting whatever they’re working on to pass tests don’t feel like writing prose about their work. This would significantly reduce the burden of work which is perceived ‘low value’ and ‘boring’ by most (yes I do review code and yes I will reject a PR without a summary).
> It isn’t stupid if it works. If this allows an engineer to spend 15 mins less time while generating good enough PR descriptions, that’s a huge win...
It can't work, unless it's hooked up to a brain scanner and can read your thoughts.
It seems more like dumb thing that people who don't know what they're doing will think is smart.
> IME people after getting whatever they’re working on to pass tests don’t feel like writing prose about their work.
Communication is part of the job. How many well-paid and creative professions get to just "nope" out if their responsibilities like that?
Those 15 saved minutes you will have to spend to validate that generated message actually makes sense. And if you are not careful, you will have to spend much more time 'rewriting history' later.
Also if an engineer has troubles describe change than maybe you don't want that change to end up in you repo.
These things are going to drive me crazy. I think stuff generated by an AI like this should have to be tagged. It’s infuriating to waste one’s time trying to read an interpret a message (or some code), trying to understand the author’s intent, only to realize the author merely pressed a “generate a bunch of code/text” button and I’m spending time trying to interpret shit the author didn’t even spend time writing.
My experience with this hitherto relates to terrible scaffolded/generated code. I’m scratching my head wondering “why did s/he do it this way?” only to realize the nonsense code was lazily churned out by some generator. I wish this stuff was labeled clearly.
Wait, if the tool can derive the commit message from the delta, then why does it need to be part of the commit? You could improve the algorithm behind the commit message later.
This is where my thoughts went as well: it's like a data structure that includes 2 numbers and their sum. Then I thought that this particular operation is not just a sum and having the memoized value could make sense: using GPT to generate the commit message for a few thousand commits would be pretty expensive.
Is there a name for the phenomenon where new automation is disparaged by comparing it to the best human outputs, rather than considering what the average human output looks like and asking if it's a net improvement on that?
Like, in this case, I would guess that the vast majority of commit messages are something like "foo", "fixed", "argh", "stupid CI thing try 10", etc. Pretty sure GPT can improve on those.
I see your point and I agree, this would be a great improvement compared to all my 'wip' commits.
I'd be more excited to use GPT to draft a summary of release notes by scanning all the new PRs in a release, summarizing what they are, and dividing them up into categories (bug fix, feature, breaking changes, etc.)
I've been using conventional commits for that, if there was equivalent of this that conformed to the CC standard then I would give it a try
See also: https://github.com/RomanHotsiy/commitgpt
Nice! Thanks for sharing. This feels far more useful to me than OP. The idea of having to push your code to github to have it generate the commit message makes me immensely sad (even for repos that are already on github, but especially when they are on gitlab).
Thanks for mentioning! I posted it to "Show HN" last week but it didn't get lots of attention back then.
It seems to me that a lot AI is used as either tool to solve made up problems or as a bad solution to real problems. This seems like the former. Who is the target audience? I'm baffled.
One problem with this I can see is that it's quite easy to write a delta that's larger than 4096 tokens minus prompt length (the maximum amount of context gpt-3 can process), and if the delta's so short it's less than that then it's not particularly necessary to use the AI to generate the commit anyway.
I made an `npx` command to add this awesome tool to codebases:
`npx add-gpt-summarizer@latest`
The CLI will walk you through all the setup steps. source code: https://github.com/soof-golan/add-gpt-summarizer
The title is a little bit misleading.
It doesn't write commit messages, it generates PR summary.
I wouldn’t be at all surprised if this improved the level of commit messages overall.
In addition to the other issues (eg. it can only explain the what) I'm low-key disappointed that the repository isn't using itself. It would undoubtedly have lead to an increase in commit message quality here.
Examples! Please!
Please add functionality so that you can show some sort of badge on your GitHub profile based on your use of this. It would be a great tool to sort out who actually understands the purpose of a commit message.
I can absolutely see how a tool like this could provide a useful hook, to reject any commit messages that do not provide information above what GPT3 can do.
And how would you determine that's it's worse? More AI?
I'll just start writing bad commits now and assume that robots will fix it up later. In fact I might as well start many years ago.
The crazy thing is chatgpt is still primitive. A decade more of working with these models will be stunning
Love the concept, but don't run this on company code without approval!
I get the appeal of offloading toil to AI. But gotta be careful to not mistake thinking for toil. Sometimes thinking is hard and not fun but that doesn't make it toil.
Writing good commit messages is thinking, not toil. 90% of the time is even easy, one line description, good to go. The other 10% is when you gotta do the thinking, though. Extracting the relevant changes from the incidental ones, summarizing the whys, the pros and cons, the weird interactions that lead to the specific choices made in the code. This is not toil, it's thinking. It's not even a matter of whether AI can do it well (for this 10%, I'm *very* skeptical it can), the issue is that this is the kind of thinking you should *want* to do, that you should want to get better at.
TL;DR: this feels like asking the computer to jog for you and expect to loose weight.
While we're making tools for developers, make it so that I can yell at my computer, have it run voice recognition on it, and have ChatGPT interact with Jira for me.