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.
Yeah this project is great, it's exactly the kind of tedious work that should be automated by AI. Some weirdos are going to mythologize commit messages and MR descriptions like they aren't our industry's version of pointless paperwork.
They aren’t pointless. They are (or at least can be) useful documentation. If they’re pointless, why bother generating them with AI instead of just leaving them blank?
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 know another single char user, and couldn't believe it either. I think possible options are a-z and 0-9, so only 36 people in the world got that lucky.
totally agree. in principle, commit histories should be treated as immutable, especially on shared or production branches.
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.
They are. If you rewrite history, you get a different hash. You can do some shenanigans with git-replace, but those are usually for stitching history across gaps (like hooking pre-publish history to public release for internal archaeology at least.
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?
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.
Yeah, "fixed it" doesn't provide any information that might be hallucinated.
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.
Good point. The purpose of git-rewrite-commits isn’t to "polish" history or rewrite meaning, it’s more of a rescue tool for those chaotic early stages of side projects (like mine) where commits are basically "update again" for months.
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.
Agreed! I've already added several warnings and disclaimers to the README :)
It's really meant to be a "use it once or twice in your lifetime" kind of tool, not something to run on every project. Actually, mostly shouldn't.
> those chaotic early stages of side projects (like mine) where commits are basically "update again" for months.
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.
Sorry, but this holier than thou attitude is silly. If you’re working on a side project after your kids are in bed and you want to write “did stuff” as your commit message, you don’t have to feel like you’ve committed a sin.
Ha! I practice good commit hygiene---even when no one's paying me---because it's useful to my future self, but I don't think pride in one's work (especially through importing workplace best practices) is a great reason, especially not a normative one. I think of this like the proverbial carpenter finishing the back of a drawer though no one will see it. It's done for the carpenter's sake, out of principle or mundane Calvinism, and I wouldn't begrudge a carpenter who didn't. And the latter might sell more furniture.
But yeah, if someone made a cabinet with fancy Japanese joinery that turns out to be inkjet AI-generated veneers over glue and nails... I would not buy it.
I think it’s a great justification. It’s a side project. It’s supposed to be fun. If you hate writing commit messages, though, of course you can always just commit with the amend option and force push. But in general I think side projects are better the fewer rules they have.
Not all git messages are equal. My $0.02 is that commit messages I write are for other people. Until I officially hand a branch over for other people's consumption, like a PR, if I'm committing the only reason is because I want to access my code on another machine. I'll put whatever junk I please in those commit messages. But then before I open a PR I'll collapse everything down into 1+ commits each with curated content and appropriate messages.
> My $0.02 is that commit messages I write are for other people.
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.
This project shows that git messages aren't just for other people as it's an attempt to make terrible messages usable for the person who wrote the code in the first place.
Git commit messages are nothing to obsess about. If you're worrying about a "messy" git commit history, you're not moving forward, you're stuck in the past, and that indicates bigger problems. The only thing that really matters to me is the state of the code today, not 500 git commits ago. But I don't know what kind of work you do, I just know I don't have time to obsess about anyone's git commits from weeks or months ago. I just know where the code is today, and where I need it to be in the next iteration. Sure, write a basic commit message, but don't waste time on it. And don't obsess about "rebuild" commits or whatever extraneous thing that needs a commit. It isn't going to matter if you're always moving forward.
> 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.
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.
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.
Counterpoint: LLMs seem to depend on robust, stable, and easy to use libraries nearly as much as we do. Due to context limitations, vibe-coding a mega-monolithic project in one shot with zero dependencies would be a silly exercise. Therefore, there is still a use for sharing code, even if plenty of it is agentic.
Using a library keeps the context window smaller than writing it all yourself. I also suspect the whole vibe-coding thing works best when most of the total running code is NOT vibe-coded, and follows carefully defined behavior the fast-and-loose parts can build on top of.
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.
honestly, I used to like writing README files before the AI (see my other repos), but I don’t like writing them anymore. GPT does it really well, it may have some mistakes but thankfully, you guys highlight them :)
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.
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.
Yeah this project is great, it's exactly the kind of tedious work that should be automated by AI. Some weirdos are going to mythologize commit messages and MR descriptions like they aren't our industry's version of pointless paperwork.
The number one audience for commit messages is yourself.
If you don’t have respect for your future self, don’t expect me to have respect for you.
They aren’t pointless. They are (or at least can be) useful documentation. If they’re pointless, why bother generating them with AI instead of just leaving them blank?
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've never seen a single character github username. I thought there was always a minimum number of characters!
I've created my account ~16 years ago :)
Do you get a lot of misdirected notifications from people who write the wrong `@`?
it's like, every day ;_;
I used to have a rather short, pithy gmail address back in the day. I binned it for gerdesj@ instead - a username which I use nearly everywhere.
A one char ID on a web app is all very well but is the extra hassle worth it?
Nope, just seems cool.
Yeah, same rationale that Elon shared for renaming Twitter to X, so for good or evil you have that trillionaire mindset pinned down.
I know another single char user, and couldn't believe it either. I think possible options are a-z and 0-9, so only 36 people in the world got that lucky.
Git commit histories should be immutable.
There's actually a mechanism in Git to add notes to commits after the fact, unsurprisingly called notes
only once pushed or merged to a shared branch.
totally agree. in principle, commit histories should be treated as immutable, especially on shared or production branches.
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.
They are. If you rewrite history, you get a different hash. You can do some shenanigans with git-replace, but those are usually for stitching history across gaps (like hooking pre-publish history to public release for internal archaeology at least.
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?
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.
Yeah, "fixed it" doesn't provide any information that might be hallucinated.
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.
Good point. The purpose of git-rewrite-commits isn’t to "polish" history or rewrite meaning, it’s more of a rescue tool for those chaotic early stages of side projects (like mine) where commits are basically "update again" for months.
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 think that's perfectly fine on a branch. I don't see this being deploying on the main branches of any projects of note.
Agreed! I've already added several warnings and disclaimers to the README :) It's really meant to be a "use it once or twice in your lifetime" kind of tool, not something to run on every project. Actually, mostly shouldn't.
> those chaotic early stages of side projects (like mine) where commits are basically "update again" for months.
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.
Sorry, but this holier than thou attitude is silly. If you’re working on a side project after your kids are in bed and you want to write “did stuff” as your commit message, you don’t have to feel like you’ve committed a sin.
> 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.
Because no one's paying you, and you owe your users nothing?
> Because no one's paying you
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.
Ha! I practice good commit hygiene---even when no one's paying me---because it's useful to my future self, but I don't think pride in one's work (especially through importing workplace best practices) is a great reason, especially not a normative one. I think of this like the proverbial carpenter finishing the back of a drawer though no one will see it. It's done for the carpenter's sake, out of principle or mundane Calvinism, and I wouldn't begrudge a carpenter who didn't. And the latter might sell more furniture.
But yeah, if someone made a cabinet with fancy Japanese joinery that turns out to be inkjet AI-generated veneers over glue and nails... I would not buy it.
I think it’s a great justification. It’s a side project. It’s supposed to be fun. If you hate writing commit messages, though, of course you can always just commit with the amend option and force push. But in general I think side projects are better the fewer rules they have.
Not all git messages are equal. My $0.02 is that commit messages I write are for other people. Until I officially hand a branch over for other people's consumption, like a PR, if I'm committing the only reason is because I want to access my code on another machine. I'll put whatever junk I please in those commit messages. But then before I open a PR I'll collapse everything down into 1+ commits each with curated content and appropriate messages.
> My $0.02 is that commit messages I write are for other people.
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.
This project shows that git messages aren't just for other people as it's an attempt to make terrible messages usable for the person who wrote the code in the first place.
Git commit messages are nothing to obsess about. If you're worrying about a "messy" git commit history, you're not moving forward, you're stuck in the past, and that indicates bigger problems. The only thing that really matters to me is the state of the code today, not 500 git commits ago. But I don't know what kind of work you do, I just know I don't have time to obsess about anyone's git commits from weeks or months ago. I just know where the code is today, and where I need it to be in the next iteration. Sure, write a basic commit message, but don't waste time on it. And don't obsess about "rebuild" commits or whatever extraneous thing that needs a commit. It isn't going to matter if you're always moving forward.
> 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.
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.
I'm guessing that the intent is deducible from the diff a pretty large percentage of the time.
I didn't find it too deducible when OP removed the acknowledgements section after another commenter called them out on the AI slop [1]
docs(readme): remove acknowledgments section [2]
[1]: https://news.ycombinator.com/item?id=45871258
[2]: https://github.com/f/git-rewrite-commits/commit/210ada7ec78f...
Really? Almost always I feel the diff captures only the how, not the why.
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.
Counterpoint: LLMs seem to depend on robust, stable, and easy to use libraries nearly as much as we do. Due to context limitations, vibe-coding a mega-monolithic project in one shot with zero dependencies would be a silly exercise. Therefore, there is still a use for sharing code, even if plenty of it is agentic.
LLMs only "depend" on libraries because library usage is in their training set. Clearly they don't actually need to use libraries.
Using a library keeps the context window smaller than writing it all yourself. I also suspect the whole vibe-coding thing works best when most of the total running code is NOT vibe-coded, and follows carefully defined behavior the fast-and-loose parts can build on top of.
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.
Why bother indeed!
Interesting that OP removed this [1] from the README and didn't explain why in their commit message or by replying to this comment.
[1]: https://github.com/f/git-rewrite-commits/commit/210ada7ec78f...
honestly, I used to like writing README files before the AI (see my other repos), but I don’t like writing them anymore. GPT does it really well, it may have some mistakes but thankfully, you guys highlight them :)
[flagged]
"Have curious conversation; don't cross-examine."
"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."
https://news.ycombinator.com/newsguidelines.html
> docs(readme): remove acknowledgments section
Heh. I wonder if the author asked GPT to remove that section from the readme.
yes that’s what I’ve done! :)
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.