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.

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.

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

[1]: https://github.com/f/git-rewrite-commits/commit/210ada7ec78f...

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?