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.

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've created my account ~16 years ago :)

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.

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"

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 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

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.

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.

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.

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'm guessing that the intent is deducible from the diff a pretty large percentage of the time.

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.

> docs(readme): remove acknowledgments section

Heh. I wonder if the author asked GPT to remove that section from the readme.

> conventional commits specification

Please stop following this. It provides zero value.

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...