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 see it as the same issue as doctor's notes. They're extremely useful but it's a waste of time to actually make the doctor do them. At some places it's a person's whole job to follow around a doctor and do all the busy work for them.
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.
As someone whos commit message are: fix, fix again, this hopefully works, again.
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
My secret is intent (and magit). If I’ going to write code, I already have a few goals in mind. That’s what I put in the commit message. Magit is for I did other stuff, so I can stage individual hunks/lines instead of whole files.
My favorite git command is git commit --amend, my second is git rebase. Until you push, you don't need to keep adding new pointless commits
Actually I wish that we had two branches in parallel, one with cleaned up commits, another with how the software were actually edited. But we need tooling for that
If you go all the way to where the cleaned-up version is a squash merge, as so many unfortunately do, we already have that: regular, non-squashed merges.
If you don't go that far, you could mimic something like it with sub-branches and merge commits for each one into your working branch, but I imagine it would be annoying to handle at that granularity.
I've literally never gone over my old commit messages on any personal projects.
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.
I actually have. I have a bunch of long-running projects, and it has sometimes been useful to be able to look back to the commit that added some behavior I'm not sure about now and go "oh, okay, this was part of a commit in 2014 where I said I was doing X".
(And sure, you could also say that I should have added better documentation back in 2014...)
The messages are for other people, also it's like any type of writing: tremendous value in the process of writing. in that way, i'm agreeing with the parent, it is for yourself. The process of writing commit messages is useful to yourself.
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.
I tend to write actual documentation or notes as I'm working on the software, even for personal projects. This is far more useful to me than commit messages.
A better question is why anyone should bother to take their time to read something that's not worth yours to write. This goes for most of AI output, honestly.
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.
I would be more interested in an hybrid approach, an AI that when has low confidence in a generated commit message asks the user for their input: "Was this change meant to fix a bug? y/n" and about splitting commits "you changed 6 html files and 1 SQL file, they seem unrelated" should I split that into 2 separated commits? y/n"
The value of the space is whatever the user/team finds valuable.
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.
But you see now my LLM can use less tokens to parse his commit messages instead of the entire code base to then boil it all down to "85-- minor-- inconsequential-- commits emdash emdash emojji"
> 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 maintain their own code will already do themselves, at commit time, with `git add -p` (and before commit time, by having the discipline to avoid getting distracted solving a second problem while in the middle of solving the first!) And it's also exactly the format that patch-based workflows like LKML already expect contributors to construct [from whatever they were doing internally] when submitting a patch-series, to allow the patch to be read and considered on the mailing list as essentially a linear literate-programming explanation of the changes.
The tool still wouldn't be able to recover the intent of each patch series if it was never added; so the commits would still just be descriptions of the kind a later "software archaeologist" or reverse-engineer would give to the code. But it would at least be generating descriptions for coherent chunks of code, rather than attaching descriptions to commits that were essentially "whatever probably-partial progress on whatever incoherent set of things the programmer was trying to do at the time they needed to sync their work to switch from their laptop to their workstation."
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.
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)
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.
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.
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
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
This is the perfect product description for how a tool like this should actually work. Not git-rewrite-history, but something like git-explain-commit <hash>. It would take the diff, run it through an LLM at request time, and give you a summary. And yes, with an [Generated by Model XYZ] tag right at the top. This would preserve the integrity of the history while giving us all the power of AI to analyze it, without the downsides of permanent changes and fossilized AI slop
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
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.
I don't think that's the idea; it's more that when you're not beholden to an employer, you can focus on (and take pride in) whichever aspects of the work you want to focus on. When I'm working on my own projects, most of the pride I take in my code is based on what it does -- not on how clean it is, and certainly not on how well organised is the repository it lives in.
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.)
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 this is 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.
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.
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.
500 commits ago was 10 commits ago at some point in time. And it can be 5 commits ago for part of the code. Imagine looking ar some function and wanting to know why a particular step exists. It’s easy to do a quick blame, then find out it was modified in 2020 to fix some issue. Then quicky scan the message and diff to capture the reasoning behind the change.
That is why good summary and atomic commits are important. They exist in the time dimension.
None of that has ever, in 40 years of programming, been very important to me. Again, the only thing that really matters to me is the state of the code today, and the direction the code needs to go in. Where the code has been simply doesn't matter very much to me (YMMV). Git commit history has had so little value to me in practice that it's almost completely pointless to worry about. But again, YMMV.
> 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 :)
> Please respond to the strongest plausible interpretation of what someone says
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.
Since the HN community is obviously not reviewing every commit in all of the OP's repos, I imagine that the last bit ("you guys highlight them") was a light-hearted reference to the current thread.
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.
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 see it as the same issue as doctor's notes. They're extremely useful but it's a waste of time to actually make the doctor do them. At some places it's a person's whole job to follow around a doctor and do all the busy work for them.
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.
At least a scribe captures the doctor's thoughts. AI is not capturing the author's thoughts because it doesn't know what they were at commit time.
As someone whos commit message are: fix, fix again, this hopefully works, again.
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
My secret is intent (and magit). If I’ going to write code, I already have a few goals in mind. That’s what I put in the commit message. Magit is for I did other stuff, so I can stage individual hunks/lines instead of whole files.
My favorite git command is git commit --amend, my second is git rebase. Until you push, you don't need to keep adding new pointless commits
Actually I wish that we had two branches in parallel, one with cleaned up commits, another with how the software were actually edited. But we need tooling for that
If you go all the way to where the cleaned-up version is a squash merge, as so many unfortunately do, we already have that: regular, non-squashed merges.
If you don't go that far, you could mimic something like it with sub-branches and merge commits for each one into your working branch, but I imagine it would be annoying to handle at that granularity.
[dead]
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.
I've literally never gone over my old commit messages on any personal projects.
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.
I actually have. I have a bunch of long-running projects, and it has sometimes been useful to be able to look back to the commit that added some behavior I'm not sure about now and go "oh, okay, this was part of a commit in 2014 where I said I was doing X".
(And sure, you could also say that I should have added better documentation back in 2014...)
I usually use blame to find commits in those situations.
The messages are for other people, also it's like any type of writing: tremendous value in the process of writing. in that way, i'm agreeing with the parent, it is for yourself. The process of writing commit messages is useful to yourself.
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.
I tend to write actual documentation or notes as I'm working on the software, even for personal projects. This is far more useful to me than commit messages.
even better!
A better question is why anyone should bother to take their time to read something that's not worth yours to write. This goes for most of AI output, honestly.
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.
I would be more interested in an hybrid approach, an AI that when has low confidence in a generated commit message asks the user for their input: "Was this change meant to fix a bug? y/n" and about splitting commits "you changed 6 html files and 1 SQL file, they seem unrelated" should I split that into 2 separated commits? y/n"
That actually sounds like a good match for LLMs' ability to do fuzzy intuition and pattern-matching.
this is a really good idea.
The value of the space is whatever the user/team finds valuable.
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.
It's not absurd, and it's also not gatekeeping.
Why do you want a summary of the changes? The bulk of the information in a commit is the diff itself.
The information that is not contained in the diff is the author's intent, and that's what the space is meant to contain.
I'm not convinced you actually believe that a summary is valuable because this whole comment is coming from a very defensive place.
But you see now my LLM can use less tokens to parse his commit messages instead of the entire code base to then boil it all down to "85-- minor-- inconsequential-- commits emdash emdash emojji"
> 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 maintain their own code will already do themselves, at commit time, with `git add -p` (and before commit time, by having the discipline to avoid getting distracted solving a second problem while in the middle of solving the first!) And it's also exactly the format that patch-based workflows like LKML already expect contributors to construct [from whatever they were doing internally] when submitting a patch-series, to allow the patch to be read and considered on the mailing list as essentially a linear literate-programming explanation of the changes.
The tool still wouldn't be able to recover the intent of each patch series if it was never added; so the commits would still just be descriptions of the kind a later "software archaeologist" or reverse-engineer would give to the code. But it would at least be generating descriptions for coherent chunks of code, rather than attaching descriptions to commits that were essentially "whatever probably-partial progress on whatever incoherent set of things the programmer was trying to do at the time they needed to sync their work to switch from their laptop to their workstation."
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.
My username was f before Elon made Twitter X.
Bit of a leap.
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.
That got me curious. My Github username is three characters but includes a hyphen.
Turns out it's a valid single-character name as well on GH:
https://github.com/-
No UTF-8 support?
It's funny, on mobile the ellipsis Github uses to truncate the username in the path actually takes up more space than if they just showed the "f"
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)
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.
Why would you force a ticket number in the commit header? That belongs in a trailer, which you can still enforce and analyze.
Also please kill conventional commits, that info should be in a trailer too.
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.
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
This is coool, haha. I remember spending time on git rebase to satisfy my OCD.
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
This is the perfect product description for how a tool like this should actually work. Not git-rewrite-history, but something like git-explain-commit <hash>. It would take the diff, run it through an LLM at request time, and give you a summary. And yes, with an [Generated by Model XYZ] tag right at the top. This would preserve the integrity of the history while giving us all the power of AI to analyze it, without the downsides of permanent changes and fossilized AI slop
that makes sense!
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
Git commit histories should be immutable.
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.
only once pushed or merged to a shared branch.
There's actually a mechanism in Git to add notes to commits after the fact, unsurprisingly called notes
In the case of Git, the fact that they have a reasonable name is rather surprising.
huh TIL. Does GitHub show these notes in the UI?
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?
Not sure I agree, I don't even remember how many times I have moved HEAD down.
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.
> 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.
I don't think that's the idea; it's more that when you're not beholden to an employer, you can focus on (and take pride in) whichever aspects of the work you want to focus on. When I'm working on my own projects, most of the pride I take in my code is based on what it does -- not on how clean it is, and certainly not on how well organised is the repository it lives in.
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.)
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 this is 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.
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.
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.
500 commits ago was 10 commits ago at some point in time. And it can be 5 commits ago for part of the code. Imagine looking ar some function and wanting to know why a particular step exists. It’s easy to do a quick blame, then find out it was modified in 2020 to fix some issue. Then quicky scan the message and diff to capture the reasoning behind the change.
That is why good summary and atomic commits are important. They exist in the time dimension.
None of that has ever, in 40 years of programming, been very important to me. Again, the only thing that really matters to me is the state of the code today, and the direction the code needs to go in. Where the code has been simply doesn't matter very much to me (YMMV). Git commit history has had so little value to me in practice that it's almost completely pointless to worry about. But again, YMMV.
> 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
> Please respond to the strongest plausible interpretation of what someone says
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.
Since the HN community is obviously not reviewing every commit in all of the OP's repos, I imagine that the last bit ("you guys highlight them") was a light-hearted reference to the current thread.
> conventional commits specification
Please stop following this. It provides zero value.
> 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! :)
You should drop the conventional commits nonsense. “docs(readme):” provides less than zero value.
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.