git revise: a rebase that leaves your working tree alone

The difference is what it refuses to touch

git revise is a git subcommand to efficiently update, split, and rearrange commits, and the README states the difference from the tool it is modelled on in one paragraph.

The tool is heavily inspired by git rebase, but it tries to be more efficient and ergonomic for patch-stack oriented workflows. By default, git revise applies staged changes to a target commit, then updates HEAD to point at the revised history, and it also supports splitting commits and rewording commit messages.

The mechanism that makes it different is stated next: unlike git rebase, git revise avoids modifying the working directory or the index state, performing all merges in-memory and only writing them when necessary. The README gives the two consequences directly. It allows it to be significantly faster on large codebases, and it avoids unnecessarily invalidating builds.

That second consequence is the one that matters in practice. A rebase that checks out each commit in turn rewrites the files on disk, and a build tool that keys on file timestamps or hashes will rebuild everything. In a large repository that is often the entire cost of the rebase, not the merge itself. A tool that computes the new history in memory and writes it at the end touches the files once.

The other half of the design is the workflow assumption. The target is a patch stack, the sequence of commits on a branch that you intend to send upstream, and the operations are the ones that stack needs: fold staged changes into a commit, split a commit in two, and reword a message. The keywords in the package metadata say the same in five words: git, revise, rebase, amend, fixup.

Update, split and reword, in that order of use

Three operations are named in the README, and the default one is the first.

Update means taking what you have staged and applying it to a commit somewhere below HEAD, then moving HEAD to the rewritten history. That is the fixup workflow, the situation where you have been working on one commit in the middle of a stack and want to fold the current change into it. The staged state is the input, which is why the tool's design keeps the index untouched in the output, and why the command reads naturally as a subcommand rather than as a mode with a bunch of flags.

Split means dividing a commit into two, which is the operation you need when a commit turns out to contain two unrelated changes and the reviewer of your stack will ask for them to be separated.

Reword means changing a commit message, which in a patch stack is how you fix a message that the upstream maintainer will read.

The README is short on all three, deliberately so, because the detail lives in the documentation hosted on Read the Docs, which the README links as the place for usage and examples. That is the first thing to read after the installation, and it is a reasonable division of labour: the README explains what the tool is for and why it exists, and the manual explains how to drive it.

The man page is the other half of the documentation story, and the packaging makes sure it lands in the right place. The wheel's shared data section installs git-revise.1 as share/man/man1/git-revise.1, so the manual page is available wherever the platform's man page directory is, and the repository has the git-revise.1 file at its top level.

Three install paths, and more from other people

Installation is a one-liner from PyPI:

pip install --user git-revise

The --user flag is the usual choice for a git subcommand, since it puts the script in your own path rather than in a system directory that needs root.

There are also platform packages, and the README credits the people who made them. On macOS through Homebrew:

brew install git-revise

And on Fedora:

dnf install git-revise

The README notes that various people have also packaged git revise for platform-specific package managers, so the two above are the documented ones and there may be others.

There is one detail about how a git subcommand is installed that is worth knowing, because it explains the packaging. A command named git revise is invoked as git revise, and Git finds it by looking for a git-revise executable on the path. The package therefore has to install a program called git-revise, and the project metadata does that with a script entry point, git-revise = gitrevise.tui:main.

That entry point is also a hint about the shape of the tool. The module it points at is called tui, so the interaction is a terminal user interface rather than a set of flags, and the man page is the reference for the options it takes.

Packaging details that say how the project is run

The package metadata is short and says a lot.

The build backend is hatchling, and the version is dynamic, with the tool.hatch.version path pointing at gitrevise/__init__.py, so the version lives in the package rather than in the build file. The project name is git-revise and the description is Efficiently update, split, and rearrange git commits, with the keywords git, revise, rebase, amend and fixup.

The Python floor is 3.8, and the classifiers list 3.8, 3.9 and 3.10, so the project has not been updated to declare newer versions. That is a deliberate compatibility choice for a developer tool that people install on whatever machine they have, and it also means the code has to run on an interpreter old enough that some newer syntax is unavailable.

The licence is MIT, and the classifier confirms it. The development status is 4 - Beta, and the environment is Console, with topics under version control and version control for Git.

Two build details are worth a second look. The wheel targets only the gitrevise package, and the sdist includes the same directory, which means the tests and the docs are not shipped in the source distribution, so an end user installing from a source tarball gets the code and nothing else. The shared-data section is what puts the man page in the right directory, and the man page is a separate file in the repository root rather than being generated, so it is edited by hand.

A test and lint stack that takes itself seriously

The repository listing is a typical modern Python project, and the tooling is extensive for a tool of this size.

There is a tests/ directory and a tox.ini, and the development dependency group includes tox and tox-uv together with pytest and pytest-xdist, which is the combination for running the suite across multiple processes. Sphinx is there for the documentation that is published on Read the Docs, and readthedocs.yml configures that build. twine is in the list for uploading releases to PyPI, and typing-extensions is there for the type annotations.

For static analysis there are three tools with separate configuration files: mypy with a mypy.ini, ruff pinned to a range between 0.9.6 and 0.16.0, and pylint, whose configuration lives inline in pyproject.toml under tool.pylint.messages_control. That block disables a list of messages, and the visible entries are missing-docstring, too-few-public-methods, too-many-arguments and a fourth that is cut off in the manifest. The pattern is telling: the project does not want every function documented, and it accepts that some of its interfaces take many arguments.

isort has its own .isort.cfg and its own version pin, separate from ruff, which is a slightly old-fashioned arrangement for a project that otherwise uses current tooling. The lock file is uv.lock, so the development environment is resolved with uv, and the project also has a CHANGELOG.md and a .github/ directory.

Taken together, this is a project that treats its developer tooling as part of the deliverable, which is a good sign for a tool whose whole job is to rewrite your history safely.

Maintenance, and what to check before you trust it with a branch

The last push to the repository was on 2026-06-19, and the repository is not archived. There are no GitHub releases, so the published history of the tool is the PyPI versions and the CHANGELOG.md in the repository, which is the file to read when you want to know what a given version changed.

The beta classification is the other thing to hold in mind. The project describes itself as being in development status 4 - Beta, and the README does not claim otherwise. For a tool that rewrites commit history, a beta label is not a criticism so much as an accurate description of the risk: the tool computes a new history in memory and then writes it, and the failure mode of a bug there is a branch that no longer says what you thought it said.

So there are two checks worth doing before you point it at a branch with real work on it. Read the documentation for the split and reword operations, since the README only names them, and know that the tool's model is that your staged changes are the input, so a dirty working tree with the wrong thing staged will produce a different result than you expect.

What the project does well is the part it claims. It is a subcommand rather than a wrapper script, it does not rewrite your files to compute an answer, and it is packaged for the three platforms most people run git on, with a man page so that git revise --help and man git-revise both work.

Editorial conclusion

Adopt git revise if you work in a patch stack and your rebase time is dominated by checkout and index churn, because doing the merges in memory is exactly the trade it makes, and the payoff is a fast revise and a build cache that stays warm. Do not adopt it expecting the interface of git rebase, since it is its own subcommand with its own terminal UI, and read the Read the Docs pages before you rely on the split and reword options, which the README only mentions in a sentence. Before you install it, check that your Python is 3.8 or newer, since the package declares that floor, and expect a beta: the classifier says Development Status 4 - Beta, the repository publishes no GitHub releases, and the CHANGELOG.md is the only record of what changed.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mystor/git-revise on GitHub
4. README