Simon Willison has released commit-rewriter 0.1, a small web app that lets you edit git commit messages in bulk before a repository goes public. He built it to clean up the commit history for the Datasette security releases, according to his announcement, because the original commits were “full of coding agent cruft and references to issue IDs from our private repository” and “weren’t fit for publication.”
It’s a narrow tool solving a very specific problem. That’s exactly why it’s worth a look.
What it does
The workflow is simple: run one command, edit messages in a browser, submit. Here’s what happens under the hood.
- One-line launch. Run
uvx commit-rewriter path/to/repoand the app opens against that repository. Skip the path if you’re already inside the repo directory. No install step, since uvx handles the Python packaging. - Browser-based editing. Instead of wrestling with interactive rebase in a terminal, you edit commit messages through a web interface. Willison describes it as a “little web app,” so don’t expect a full git client. It does one job.
- Automatic safety branch. When you submit your edits, the tool first creates a timestamped branch of your current repo state. If the rewrite goes wrong, you can revert to that branch. This is the detail that makes it usable on real work.
- Rewrites from the first edit forward. The tool rewrites every commit from the earliest one you changed through to the most recent. That’s how git works: change one commit hash and everything downstream changes too. Commit-rewriter handles that chain for you.
Why coding agents created this problem
What stands out here is the motivation. Willison didn’t build this because git rebase is hard. He built it because AI coding agents leave a mess in your commit log.
Agents like Claude Code and Codex write commit messages as they go. Those messages often include internal reasoning, references to private issue trackers, and verbose descriptions that read fine in a private repo but look sloppy or leak information when published. Security releases raise the stakes further, since you’re publishing fixes that reference vulnerabilities and you want the public record to be clean and deliberate.
This is a pattern I expect to see more of. As agents take over more of the day-to-day commit work, developers need a cleanup layer between “agent did the work” and “humans see the history.” Commit-rewriter is one of the first purpose-built tools for that gap.
Who should use it
A few obvious cases:
- Open-sourcing a private repo. Strip internal ticket IDs and agent chatter before the history goes public.
- Security releases. Willison’s own use case. Make sure the commit log says what you want it to say and nothing more.
- Cleaning up agent-driven branches. If an agent produced 30 commits with messages like “fix the thing from the previous commit,” you can turn those into something a human reviewer can follow.
Caveats
Rewriting history changes commit hashes. If anyone else has already pulled the commits you’re editing, they’ll hit conflicts when you force-push. Use this on branches you own, or on repos that haven’t been shared yet. Willison’s timestamped backup branch protects your local state, but it can’t protect collaborators who already have the old hashes.
It’s also a 0.1 release. Willison built it “the other day” for his own needs, so expect rough edges and a feature set that matches his workflow rather than everyone’s.
Availability
Commit-rewriter is open source and available now through uvx, which means it’s free and runs anywhere Python and uv are installed. Willison reports it works on any git repository, not just Datasette projects.
Small tools like this tend to spread fast among developers who work with coding agents daily. Watch for similar cleanup utilities to appear as more teams hit the same wall between private agent output and public code. Full details, including the source, are in Simon Willison’s original post.