[KongchangAI]
· 1 min read· 607 words

commit-rewriter 0.2 Released: Now Supports Rewriting Git Commits on Any Branch

commit-rewriter 0.2 Released: Now Supports Rewriting Git Commits on Any Branch

commit-rewriter 0.2 adds a --branch flag to rewrite commit history on any Git branch.

Simon Willison has released commit-rewriter 0.2, with the core improvement being a new `--branch` command-line parameter that lets users rewrite commit history on any Git branch — not just the default. The previous version couldn't handle feature or maintenance branches, a gap directly addressed by this update in response to Issue #3. The tool runs via `uvx` with no installation required, staying true to Willison's lightweight tooling philosophy. The article also cautions that Git history rewrites change the commit hash chain and can disrupt collaborators if used carelessly on shared branches.

What's New in commit-rewriter 0.2

Developer Simon Willison has released version 0.2 of his open-source tool commit-rewriter. The key change in this update is support for non-default branches — previously the tool could only run against a repository's default branch, but now you can target any branch using a command-line flag.

Specifically, users can add the --branch parameter to specify the target branch. The full command looks like this:

uvx commit-rewriter --branch other

This change addresses Issue #3 in the project and resolves a real pain point: developers often need to clean up commit history on feature branches or maintenance branches, not just trunk branches like main or master.

What the Tool Does and When to Use It

commit-rewriter is a command-line tool for rewriting Git commit history. It runs via uvx, which means it can be invoked directly through the Python ecosystem without any prior installation — consistent with Simon Willison's preference for lightweight, zero-setup tooling.

For developers who regularly need to clean up commit messages or bulk-adjust historical records, cross-branch support significantly expands the tool's applicability. A common team scenario is keeping the main branch relatively stable while all experimental or staged work happens on separate branches. Version 0.2 makes it possible to tidy up commit history in exactly those situations.

uvx is a subcommand provided by the Python package manager uv, functioning similarly to npx in the Node.js ecosystem — it lets you run a package's CLI tool in a temporary isolated environment without globally installing it first. Under the hood, uvx automatically downloads and caches the target package on first run, then reuses that cache on subsequent calls, making the whole process nearly seamless. The advantage of this model is that it doesn't pollute your global Python environment and requires no pip install step upfront — ideal for development utilities you don't use constantly but want available at any time. uv itself is a high-performance package manager written in Rust that has gained rapid adoption in the Python community and is increasingly becoming a strong alternative to both pip and pipx.

Small Steps, Steady Iteration

Going from 0.1 to 0.2, this update adds just a single feature — but it exemplifies the typical iteration rhythm of open-source tooling: targeted improvements driven by real user feedback (Issue #3), rather than piling on a bunch of features all at once. This incremental approach helps keep the tool stable and maintainable.

Developers interested in optimizing their Git workflows can check the full release notes on the project's GitHub Release page and try out the latest version quickly via uvx.

One important reminder: any operation involving rewriting Git history should be used with caution, especially on shared branches that have already been pushed to a remote. Rewriting history can disrupt other collaborators. It's strongly recommended to back up your work or verify the results locally before proceeding.

Rewriting Git history is fundamentally about replacing or modifying existing commit objects. Common approaches include git rebase -i, git filter-branch, and the more modern git filter-repo. Because Git commits are linked via SHA-1/SHA-256 hash chains, modifying any single commit causes the hashes of all subsequent commits to change. This means that if others have already pulled from the remote branch based on the old commits, rewriting history will cause a divergence between branches — and a force push (git push --force) will overwrite the remote record, creating conflict risks for collaborators. As a result, rewriting history is generally only recommended for local branches that haven't been shared yet, or in controlled scenarios where the entire team is fully aware of and aligned on the implications.

#commit-rewriter#Git commit history rewrite#uvx#Simon Willison#Git branch#open source tool
Share:

Related articles