Perfect for [...] improving repository maintainability.
This misses the whole point of using commit messages to record intent.
At least with a bunch of "fixed it" commits I know what I'm in for. This only fools yourself and others into thinking the repository was well maintained.
I think this is the beginning of the end of Github. Who has time to read through all these new vibe-coded projects and tools? The READMEs alone are basically essays. You can always get a chuckle or two if you read long enough though, so there's that...
"
Acknowledgments
- OpenAI for providing the GPT API
- The conventional commits specification
- The git community for powerful version control tools
"
The future of sharing code is probably dead. Everything is write-only now. Vibe it yourself.
A great many stiff serious people (in my opinion) are writing very discouraging comments here. Don’t let it get you down. The whole point of hacker culture is to break rules. If that’s what you enjoy then to hell with anyone else’s opinion. I think if you’re more worried about commit history being pristine than the experience of writing code and solving problems then you’ve missed the boat that makes the profession meaningful. Similarly, though, if writing lots of high quality commit messages is your idea of a fun weekend, then go do that and don’t listen to me, either.
This feels like a step backwards and now people who never bothered to write proper, appropriate commit messages for others to start with can care even less.
I personally don't see what the use case of this is -- you shouldn't even be hired in the first place if you can't even describe the changes you made properly.
I wish something like this could be a pre-hook which would pre-fill your commit message so that at least I could see a llm commit message instead of ust the Jira-ID because we only force that one. Most of my collegues at work just write the worst commit messages and I don't understand why. They spent so much time comming up with some solution and push it and then don't explain the thinking. Sometimes I'm in a position where I can ask for following fairly simple rules like https://handbook.gnome.org/development/commit-messages.html but most of the time it looks like shit and there is no way of knowing from the commit messages what is going on in that commit. Or perhaps it could be build in into the git-ui like Gerrit or GitLab where you can generate the commit message afterwards from the commit if it's not good enough for you.
I use the GitHub Desktop AI commit message generator, which is often better than a bullshit commit message, especially for small projects. It is often sufficient (though too verbose) for simple changes, but does regularly miss the point.
But I do agree that you want the commit message to encode your reasoning for the change.
If anybody who works on one of these commit message generators is around, some requests:
1. just allow it to take any existing commit message I've already written and expand it based on the diff. that will let me have a starting point or give a crappy but directionally accurate intention explanation
2. look at surrounding code agentically
3. make the commit messages shorter and less fluffy
The value of the space is the ability to glean the commit author's thoughts, at the time they committed it.
This is extremely dissimilar to the thoughts of the author.
The value of what this emits is already handled by evaluating the diffs in the per-file history.
It's not good to throw this sort of thing over the fence, and justifying it by considering it to be wasteful of your precious time doesn't change that.
It's better to leave it blank, but a tool like this looks perfect to help someone avoid scrutiny, while simultaneously avoiding providing a tiny depiction of what they were thinking when they committed the change, at the expense of injecting vast amounts of noise.
> The value of what this emits is already handled by evaluating the diffs in the per-file history.
I mean, for the initial development/contribution/PR workflow, I agree with you: any code reviewer should be reading the diffs anyway, and if you're reading the diffs, these messages (being purely summaries derived from the code itself without the LLM having any info about developer intent) don't add anything.
But that's not the only time commit messages matter. A tool "fixing up" bad commit messages before they're pushed to a PR branch like this, might still help with later code maintenance after the code is merged:
• When you or someone else is looking at the commit lines after the fact, in e.g. `git log` to find commits to cherry-pick, such summaries would be a substitute for having to go commit-by-commit reading the diffs to find the one you're looking for. Or when doing e.g. a `git bisect`, they'd allow the likely-offender commit to "jump out" at you from the list of remaining commits, after just the first few bisect steps, without having to do 10 more iterations to narrow it down with actual rebuilds+test suite runs.
• and when someone else is looking at `git blame` while bug-hunting, or seeing the latest commit that touched each file when browsing a github repo tree, having these summaries would be the difference between having an opaque timeline of "fix" -> "fix 2" -> "fix again" -> "update" -> "fix" commits to try to keep distinct in one's head (may as well just try to recognize commits by the abbreviated git ref at that point), vs. having commits with descriptive mnemonic "names".
Note that this tool is supposed to be retroactive, not incremental. It rewrites messages for existing commits, that already had some other message when they were initially committed; it doesn't have any function that you could use to do `EDITOR=this-program git commit` and have it generate a commit's original commit message just-in-time.
As the author says in the README, this tool was created with the goal of fixing one's private git commit history before making it public. At the point when this tool would be run (i.e. at the point a developer is trying to "clean up" their private git history for publication), it's often already been long enough since you created these commits, that you likely don't actually remember what you were thinking at the time you created them. Any information about "what [you] were thinking when [you] committed" has already been lost. "The rice has been cooked", per se.
At that point, there's no value you could add by going back over the commits manually, beyond that which this program could add. In both cases, whether you or the LLM is doing it, the result would just be a reconstruction (i.e. a guess) at what the original developer was thinking/trying to accomplish at the time.
---
Which is not to say that this tool is a substitute for making good commits (instead of random-junk-drawer snapshot-your-work "WIP commits") in the first place. And, in fact, I have a feeling that this tool is not nearly as widely applicable (at least in its current form) as its author thinks it is... because "WIP commits" don't generally have any good way of summarizing them; because "WIP commits" are often not coherent single-purpose edits of the code.
A better version of this tool, I think, would be one that rewrites a private work branch / PR branch by first squashing it into a patch, and then breaks that patch back apart into a series of commits that each "do one thing", essentially introducing the change in a literate programming style where you're meant to read the commit-series top to bottom.
In other words, exactly what an experienced software engineer who knows they'll need to maint...
I agree with everything you're saying, and I think other archaeologists feel the same.
My opinionated take is: I wouldn't want to use this space for the information that this tool could provide, and rather leave it as the truth.
The truth is that it was committed without a meaningful message, and now I might recognize a chain of message-less commits, representing a moment in time where the authors were trying to figure out where they wanted to end up.
If the tool is producing this info simply by reading the diffs in the code, why not just use it when you need it, to help explain what you're digging through, instead of changing the commit history?
Either way, the critical detail is: People should get that detail out before the rice has been cooked, and that's what I do for myself, in my own private repos, and when others do that for future archaeologists, we all benefit.
This is what I think AI thrive at.
But I'm not sure if its real value or not.
We all have repos with fairly clean git history and repos with as the author said "fixes" and "updates". If there was any value in having a clean history in such repos it would have already been clean.
It would be useful to tag the autogenerated commit messages as [LLM] or something. That way I could at least know the author didn't write this themselves, and decode it accordingly. Humans and LLMs both make mistakes, but they make different styles of mistakes
Also, it seems a tool like this would be much better suited to help someone who wants more fluff understand a terse git history, than to rewrite the history. That way, you'd benefit from any later improvements of the model rather than freeze comments at whatever level of slop was the state of the art of the day
AI-generated commits are useful, as long as they act as a post-processor rather than the author. If the history is already a mess, the tool can structure it chronologically, restore the connections between changes, and describe what they mean. The main thing is that it must not change public SHAs, it needs to mark its own entries as machine-generated, and it should keep the original messages saved somewhere nearby
I actually see the value here. People love to dunk on devs whom write lazy fix or update commits, but projects aren’t linear. you’re figuring things out as you go. What makes sense at one point can look totally meaningless a few weeks later because your context changed. The real value for me would be adding why something was changed, maybe even referencing future commits so the history makes more sense in hindsight.(of course you can see that changes through commit history)
16 comments
[ 4.8 ms ] story [ 42.5 ms ] threadThis misses the whole point of using commit messages to record intent.
At least with a bunch of "fixed it" commits I know what I'm in for. This only fools yourself and others into thinking the repository was well maintained.
"
Acknowledgments
- OpenAI for providing the GPT API
- The conventional commits specification
- The git community for powerful version control tools
"
The future of sharing code is probably dead. Everything is write-only now. Vibe it yourself.
I personally don't see what the use case of this is -- you shouldn't even be hired in the first place if you can't even describe the changes you made properly.
But I do agree that you want the commit message to encode your reasoning for the change.
If anybody who works on one of these commit message generators is around, some requests:
1. just allow it to take any existing commit message I've already written and expand it based on the diff. that will let me have a starting point or give a crappy but directionally accurate intention explanation
2. look at surrounding code agentically
3. make the commit messages shorter and less fluffy
This is extremely dissimilar to the thoughts of the author.
The value of what this emits is already handled by evaluating the diffs in the per-file history.
It's not good to throw this sort of thing over the fence, and justifying it by considering it to be wasteful of your precious time doesn't change that.
It's better to leave it blank, but a tool like this looks perfect to help someone avoid scrutiny, while simultaneously avoiding providing a tiny depiction of what they were thinking when they committed the change, at the expense of injecting vast amounts of noise.
I mean, for the initial development/contribution/PR workflow, I agree with you: any code reviewer should be reading the diffs anyway, and if you're reading the diffs, these messages (being purely summaries derived from the code itself without the LLM having any info about developer intent) don't add anything.
But that's not the only time commit messages matter. A tool "fixing up" bad commit messages before they're pushed to a PR branch like this, might still help with later code maintenance after the code is merged:
• When you or someone else is looking at the commit lines after the fact, in e.g. `git log` to find commits to cherry-pick, such summaries would be a substitute for having to go commit-by-commit reading the diffs to find the one you're looking for. Or when doing e.g. a `git bisect`, they'd allow the likely-offender commit to "jump out" at you from the list of remaining commits, after just the first few bisect steps, without having to do 10 more iterations to narrow it down with actual rebuilds+test suite runs.
• and when someone else is looking at `git blame` while bug-hunting, or seeing the latest commit that touched each file when browsing a github repo tree, having these summaries would be the difference between having an opaque timeline of "fix" -> "fix 2" -> "fix again" -> "update" -> "fix" commits to try to keep distinct in one's head (may as well just try to recognize commits by the abbreviated git ref at that point), vs. having commits with descriptive mnemonic "names".
Note that this tool is supposed to be retroactive, not incremental. It rewrites messages for existing commits, that already had some other message when they were initially committed; it doesn't have any function that you could use to do `EDITOR=this-program git commit` and have it generate a commit's original commit message just-in-time.
As the author says in the README, this tool was created with the goal of fixing one's private git commit history before making it public. At the point when this tool would be run (i.e. at the point a developer is trying to "clean up" their private git history for publication), it's often already been long enough since you created these commits, that you likely don't actually remember what you were thinking at the time you created them. Any information about "what [you] were thinking when [you] committed" has already been lost. "The rice has been cooked", per se.
At that point, there's no value you could add by going back over the commits manually, beyond that which this program could add. In both cases, whether you or the LLM is doing it, the result would just be a reconstruction (i.e. a guess) at what the original developer was thinking/trying to accomplish at the time.
---
Which is not to say that this tool is a substitute for making good commits (instead of random-junk-drawer snapshot-your-work "WIP commits") in the first place. And, in fact, I have a feeling that this tool is not nearly as widely applicable (at least in its current form) as its author thinks it is... because "WIP commits" don't generally have any good way of summarizing them; because "WIP commits" are often not coherent single-purpose edits of the code.
A better version of this tool, I think, would be one that rewrites a private work branch / PR branch by first squashing it into a patch, and then breaks that patch back apart into a series of commits that each "do one thing", essentially introducing the change in a literate programming style where you're meant to read the commit-series top to bottom.
In other words, exactly what an experienced software engineer who knows they'll need to maint...
My opinionated take is: I wouldn't want to use this space for the information that this tool could provide, and rather leave it as the truth.
The truth is that it was committed without a meaningful message, and now I might recognize a chain of message-less commits, representing a moment in time where the authors were trying to figure out where they wanted to end up.
If the tool is producing this info simply by reading the diffs in the code, why not just use it when you need it, to help explain what you're digging through, instead of changing the commit history?
Either way, the critical detail is: People should get that detail out before the rice has been cooked, and that's what I do for myself, in my own private repos, and when others do that for future archaeologists, we all benefit.
Also, it seems a tool like this would be much better suited to help someone who wants more fluff understand a terse git history, than to rewrite the history. That way, you'd benefit from any later improvements of the model rather than freeze comments at whatever level of slop was the state of the art of the day