commit-rewriter 0.1 adds a local UI for cleaning Git commit messages after AI-assisted coding

commit-rewriter 0.1 is a local web application, not a hosted SaaS service and not an AI model. The documented access paths are uvx commit-rewriter /path/to/repository, pip install commit-rewriter, or uv tool install commit-rewriter. PyPI and GitHub both describe it as a local web app for editing commit messages in a Git repository. commit-rewriter · PyPI

The project depends on Starlette and Uvicorn, with Python >=3.11; its CLI entry point is commit-rewriter = "commit_rewriter:main". The default web server binds to 127.0.0.1 on port 8000, and the CLI supports -p/--port to choose another port. [](https://raw.githubusercontent.com/simonw/commit-rewriter/main/pyproject.toml)

The UI targets the latest 100 commits on main, showing editable messages, author/committer metadata, diffs, search by message/author/hash, an “edited only” filter, and a review dialog before applying changes. The interface also warns that drafts are stored in browser localStorage, descendant hashes change, invalidated signatures are removed, and no changes are pushed. [](https://raw.githubusercontent.com/simonw/commit-rewriter/main/commit_rewriter/index.html)

Exact model/version: none documented. There is no runtime LLM model dependency in the package metadata or source reviewed. The AI relevance comes from the stated use case—cleaning up coding-agent-generated commit messages—not from the tool calling an LLM. Release: commit-rewriter 0.1

The implementation is compact and direct. The central Repository class shells out to Git using subprocess.run, adding --no-replace-objects and -C <repo> to its Git invocations. It verifies the repository by running git rev-parse --git-dir and then works against a hard-coded refs/heads/main. This hard-coded branch is already visible as a limitation: an open GitHub issue asks for support for repositories that do not have main or master. [](https://raw.githubusercontent.com/simonw/commit-rewriter/main/commit_rewriter/__init__.py)

Commit enumeration uses git log -100 --format=%H refs/heads/main, then reads each commit object with git cat-file commit <oid>. Messages are decoded using the commit’s declared encoding if present, defaulting to UTF-8. Diffs are generated with git show --format=fuller --patch --binary --no-ext-diff --no-color, which means the UI can show Git’s own patch presentation rather than reconstructing diffs itself. [](https://raw.githubusercontent.com/simonw/commit-rewriter/main/commit_rewriter/__init__.py)

Before rewriting, the tool checks that the expected branch tip is still current, rejects shallow repositories, refuses unmerged indexes, and refuses active Git operations including merge, cherry-pick, revert, rebase, bisect and sequencer states. It also checks for another worktree with main checked out. These checks matter because the tool performs low-level object creation and ref updates; concurrent Git operations would make state reconstruction riskier. [](https://raw.githubusercontent.com/simonw/commit-rewriter/main/commit_rewriter/__init__.py)

The rewrite algorithm is not a wrapper around git rebase -i. It computes affected commits with git rev-list --topo-order --reverse --parents <expected>, marks a commit affected if it is directly edited or descends from an affected parent, reconstructs raw commit objects, rewrites parent object IDs through an old-to-new mapping, and writes new commit objects with git hash-object -t commit -w --stdin. It then updates refs/heads/main with git update-ref, using the old expected tip as a compare-and-swap guard. [](https://raw.githubusercontent.com/simonw/commit-rewriter/main/commit_rewriter/__init__.py)

The code creates a backup branch named under commit-message-backup/<timestamp>-<random>, pointing to the original tip before rewriting. This supports rollback as long as the backup branch is retained. However, the tool does not push the backup or rewritten history to a remote; the UI explicitly says no changes are pushed. [](https://raw.githubusercontent.com/simonw/commit-rewriter/main/commit_rewriter/__init__.py)

The test suite provides the closest thing to reproducible evaluation found today. Tests cover preservation of author, committer, dates and trees; merge topology behavior; rejection of empty/NUL messages; stale-tip detection; preservation of uncommitted staged/unstaged/untracked changes; rejection of conflicts and active Git operations; failure handling; concurrent ref-change protection; the latest-100-commit window; HTTP validation, progress reporting, CSRF enforcement and trusted-host behavior; and explicit removal of invalidated commit signatures. [](https://raw.githubusercontent.com/simonw/commit-rewriter/main/tests/test_commit_rewriter.py)

From a reproducibility standpoint, PyPI provides source and wheel hashes and provenance attestations for both distributions. The source distribution is listed at 16.5 kB, the wheel at 12.7 kB, and PyPI records Trusted Publishing with GitHub Actions as the token issuer. These are supply-chain metadata, not a code audit, but they help practitioners pin and verify the initial artifact. commit-rewriter · PyPI

Git history rewriting is a long-established workflow, usually performed with git commit --amend, interactive rebase, filter-branch, or newer tools. Git’s own book explains rewriting the most recent commit and changing older commit messages with interactive rebase, while warning not to amend commits that have already been pushed. Git - Rewriting History

The distinctive contribution here is not a new Git primitive. It is a purpose-built browser UI for one common post-agent cleanup task: rewriting many commit messages while preserving file contents and metadata. In that respect it resembles a narrow workflow tool rather than a general history surgery framework. The relevance to AI teams is that agentic coding makes messy metadata more common: commit messages may contain tool traces, private references, prompt artifacts or low-quality summaries that humans do not want in public release history. The release post’s Datasette example is evidence of that use case, but not evidence of broad prevalence. Release: commit-rewriter 0.1

Branch protection and signed-commit policies are the governance backdrop. GitHub documents branch protection rules that can restrict force pushes, require status checks and require signed commits. Those controls matter because rewritten local history only becomes a shared-history problem when pushed or force-pushed to a shared branch. About protected branches - GitHub Docs

The biggest functional limitation is branch scope: version 0.1 targets refs/heads/main, and an open issue reports that the tool does not work for repositories without main or master. [](https://raw.githubusercontent.com/simonw/commit-rewriter/main/commit_rewriter/__init__.py)

The biggest safety limitation is inherent to the task: rewriting commit messages creates new commit objects and changes descendant hashes. That is expected Git behavior, not a bug, but it can disrupt collaborators, invalidate references, and remove signatures if used on shared or signed history. Git’s documentation warns about rewriting published commits; the project UI also warns about changed descendant hashes and removed invalidated signatures. Git - Rewriting History

The HTTP surface is local by default and includes several protective measures: Uvicorn binds to 127.0.0.1, the app uses Starlette TrustedHostMiddleware for localhost-style hosts, and rewrite requests require an X-CSRF-Token. Tests assert that missing CSRF tokens are rejected and an unexpected host receives a 400. These are useful local-web-app safeguards, but not a substitute for sandboxing if an AI agent or untrusted local process can access the user’s browser/session or filesystem. [](https://raw.githubusercontent.com/simonw/commit-rewriter/main/commit_rewriter/__init__.py)

Same-day third-party commentary includes a French summary and an AI-labeled article framing the tool as an audit-trail risk. Those pieces are useful for context but do not independently verify implementation correctness or exploitation risk. The AGORÀ article itself discloses AI editorial authorship with human supervision. commit-rewriter nettoie ce que l'agent a écrit

For engineering managers, the tool is useful before publishing a previously private branch, especially for security releases where internal issue identifiers, exploit details, customer references or agent artifacts might leak through commit messages. The workflow should be treated as pre-publication cleanup, not routine post-publication editing. Release: commit-rewriter 0.1

For regulated or security-sensitive teams, the governance rule should be simple: do not allow AI agents or broad local automation to rewrite release history without human review, external logging and branch protections. If commit signatures are part of your control environment, rewritten commits should be re-signed through the normal release process, and protected branches should restrict force pushes. GitHub’s branch protection documentation supports these controls at the repository policy layer. About protected branches - GitHub Docs

For developers, the implementation is approachable and testable. The most important operational precautions are: run it only on a full clone, review the backup branch, avoid shared branches unless the team has agreed to a rewrite, verify git diff <backup> main for content equivalence after rewriting, and push only after reviewing the resulting history. The project’s tests indicate content trees are intended to remain unchanged, but teams should still verify that property on their own repositories. [](https://raw.githubusercontent.com/simonw/commit-rewriter/main/tests/test_commit_rewriter.py)