Git stays underneath, but the working model changes
Jujutsu is a version control system with its own command line. Its production-ready backend stores regular Git commits, so Git remotes still receive the history. Jujutsu keeps higher-level details such as bookmarks and its operation log outside Git. A colocated workspace lets jj and git operate on the same checkout, which supports a trial without changing the shared repository format.
The checked-out commit contained 705 files, about 266,750 lines of source, and occupied 12.6 MB before installation. That is a substantial Rust codebase, even though our automated harness classified its ecosystem as Python. The mismatch matters when reading the lab result: a passing generic install step is useful evidence about that step, but it does not replace the project's documented Rust installation path or a real Jujutsu command test.
Daily work feels different within the first commit. The working copy is itself a commit, commands snapshot it automatically, and there is no exposed staging area. Instead of git add -p followed by a commit, the comparison guide points users toward jj split; jj squash -i moves selected changes into a parent. Jujutsu also has no current branch. Bookmarks identify named lines of work, but users move them explicitly before pushing.
Undo and automatic rebasing favor stacked changes
Repository-changing commands are recorded in an operation log, which powers normal undo rather than leaving recovery as a reflog exercise. Editing an earlier commit automatically rebases its descendants, and bookmarks pointing into that stack move with the rewritten commits. Conflicts can live inside commits, so a rebase can finish while leaving resolution for later. Those choices suit developers who frequently reshape a series before review.
Version 0.44.0, released on August 6, 2026, shows both the payoff and the cost of the project's pace. It stabilized fetching and pushing tags, added interactive selection to jj absorb, and extended jj run. The same release changed tag-fetch behavior, removed an older clone flag, changed jj file search output, and altered template return types. Pinning the binary and reading release notes is part of operating Jujutsu before 1.0.
What happened when we ran it
Our sandbox install step finished in 11 seconds, adding 33 packages and using 36 MB on disk. The automated build step then succeeded in 1 second. We ran commit 9d905d5 in an unprivileged Debian container with 3 CPUs and 8 GB of RAM, using the ghcr.io/astral-sh/uv:python3.12-bookworm image.
The harness found no tests script or target, so it skipped the test step. Its scan also reported no tests directory, 9 CI workflow files, and no Dockerfile. Pip-audit reported 1 known vulnerability. The supplied result does not identify the affected package or establish its reachability, so the finding supports investigation rather than a claim about practical exploitability.
The checkout was classified as Python by the harness, while GitHub lists Rust as the primary language and the source installation guide requires Rust 1.88 or newer. We therefore would not treat the 11-second install or 1-second build as proof that Jujutsu itself was exercised end to end. The honest result is narrower: both automated steps passed, test execution did not happen, and the dependency audit was not clean.
Source installation needs Rust 1.88 and Git 2.41
Released binaries are available for Windows, macOS, and Linux. The guide also documents Homebrew, winget, Cargo Binstall, Arch, NixOS, openSUSE, FreeBSD, and other package routes. Building on Linux needs Rust 1.88 or newer plus build-essential. Runtime use requires Git 2.41.0 or later, which the guide says may force an upgrade on Debian 11 and Ubuntu 22.04.
Initial configuration only needs a user name and email, and a local repository does not require a hosted account. Remote authentication still follows the chosen Git host. The larger setup cost is teaching the model: anonymous heads replace mandatory branch naming, bookmarks do not advance as a current Git branch would, and conflicts no longer stop an operation. A team should agree on push and bookmark conventions before mixing tools in shared work.
Submodules and pre-1.0 formats rule out some repositories
The README calls Git submodule support incomplete and says native email workflows are absent. Issue #494, opened in August 2022, still tracks submodule support, while the roadmap says major user-experience questions remain. The roadmap also describes forge submission commands, an RPC API, cloud repositories, and virtual file-system work as goals without target dates. None should be treated as a promised release feature.
Storage stability is the broader limit. The maintainers say workflow changes and backward-incompatible on-disk changes will occur before version 1.0.0. They intend to provide transparent upgrades or migration help, but that is different from a frozen compatibility contract. Colocated repositories and remote Git commits reduce the consequence of a Jujutsu metadata problem, making them preferable to a Jujutsu-only pilot.
August 2026 activity supports a focused trial
The repository was pushed on August 26, 2026, and GitHub showed 812 open issues plus 405 open pull requests that day. Recently updated threads included both feature requests and reviewed code, so the combined queue sits alongside current maintainer activity. The latest release was 20 days old, and the repository had 31,205 stars. Stars do not settle reliability, but the push, release, and discussion dates argue against calling the project dormant.
Jujutsu is ready for experienced individuals and teams whose Git pain centers on rebasing, splitting, and recovering stacked changes. It is a poor universal replacement while submodules and email patches remain gaps and the storage format can still break compatibility before 1.0. Start with one colocated repository, pin version 0.44.0, and decide whether fewer history-editing interruptions justify a new mental model.