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.
You almost had the right idea there: the value of what this emits is really in the summary of diffs. I'm certainly not going to go through each commit and read the diff each time I look at the log, but I still want to understand what happened and be able to find individual commits. If extra information about the author's thoughts is just not available, I'd much rather have summaries than a blank log of "WIP" comments.
It's absurd to gatekeep commit messages to only "the thoughts of the author", even if that's what usually goes in there. A good diff summary might even be more useful than a ramble that doesn't mention important changes.
I'm not nearly important enough to have an intern write my commit messages but now that AI can do them, and do them extremely well, I'm more than happy to offload the work and get back to the actual work. The AI is far more thorough than I would be and because it takes away nearly all the mental effort the end result is, I think, better.
I am sure AI cannot even glims the frustration I feel committing these commits.
You can argue, that these messages are as poor as the code that I have written; but don't tell me you haven't been there -- and if you have please tell me your secret
If you don’t have respect for your future self, don’t expect me to have respect for you.
The only time I've ever regretted not writing better messages on personal projects is when they eventually became shared. Which is like, twice, in a decade or so and wasn't even a big deal in those cases.
So when I'm writing commit messages, it is exclusively for other people.
(And sure, you could also say that I should have added better documentation back in 2014...)
Being a good communicator is very commonly the main difference between "moving up" in one's career. Quotes because i don't want this to be a debate about IC vs management tracks.
Also please kill conventional commits, that info should be in a trailer too.
A one char ID on a web app is all very well but is the extra hassle worth it?
Turns out it's a valid single-character name as well on GH:
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
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 tool is not meant to rewrite public history or alter real project timelines. it's more of a utility for personal or experimental repos (or branches), the kind of messy ones full of "update again" commits that never had a proper history. that's exactly why I built it.
What you actually want is a ban on rewriting tags or accepting branch updates to commits that do not have the current commit as an ancestor. These hooks do exist, but are not on by default (beyond the toilet paper protection of needing --force).
You also have to ban deleting branches because otherwise you just delete and push a new one with the same name. Maybe we should store topic branches in repos under refs/topics/ to distinguish integration branches from development/review branches?
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.
Please don't use AI-generated commit messages blindly. Instead, use AI later when reading commit messages. It will have more context (following commits) to see what was actually happening. Having to guess whether a message was hallucinated by an AI won't help. If the message conflicts in its intention with what it isactually doing, you can spot the bug. You won't get that with AI messages.
Also, using AI commit messages will freeze it's capabilities in time, when creating the commit. When using AI at reading commit messages, you'll always get the latest options for analyzing the commits.
Just because it has more text doesn't make it a better message.
In those cases, the "intent" was never recorded in the first place, so the AI is just giving some structure and readability to what’s already lost context.
It’s not about pretending the repo was well maintained, it’s about making messy histories a bit more understandable for humans (and future me) without rewriting the actual code or meaning.
I don't accept "chaotic early stages of side projects" is a justification for skipping out on writing good quality commit messages.
It wouldn't be acceptable in a well managed company so I don't understand why side projects would get a pass to become sloppy.
It's your side project and you're free to skip writing commit messages, but you need to own that decision and not blame "those chaotic early stages"
I've found taking the time to write good commit messages helps me as I can see what I've tried previously and pull out any older versions if I've found a new direction isn't working for me. It also captures my thought process in case I'm tempted to repeat the sins of the past.
Because no one's paying you, and you owe your users nothing?
While I'm certainly getting there, I'm not cynical enough to believe being paid is the only reason to take pride in the quality of your work.
Yes, sometimes that makes things harder in the long run, but on the other hand there may not be a long run for this project if I try to force myself to do all the tedious bits 'correctly'. (And 99% of the time what bites me is my sloppy coding practices; it's very rare for much to hinge on the quality of my commit messages.)
I write them for my future self.
In this context we're talking about a side project which presumably won't have a PR where the commit messages are cleaned up (at least I don't do PRs for my own side projects).
If I'm on a branch then I will write junk commits and clean them up before merging to main if I actually manage to get the feature right.
I can assure you that it's very acceptable at companies of all sizes and ironically it's the most senior most experienced people who write "flerpin derpin" as commit messages.
docs(readme): remove acknowledgments section [2]
[1]: https://news.ycombinator.com/item?id=45871258
[2]: https://github.com/f/git-rewrite-commits/commit/210ada7ec78f...
"
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.
Otherwise, why bother to run your vibe-coded website on nginx? Just have the LLM spit out its own novel web server, its own novel TCP stack, its own novel OS for that matter.
[1]: https://github.com/f/git-rewrite-commits/commit/210ada7ec78f...
"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."
What is the "strongest plausible interpretation" of that comment? Because I interpreted it in the exact same way, and don't really see any other possible interpretation.
Please stop following this. It provides zero value.
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.