Jujutsu in 2026: an architecture note on the operation log, working-copy commits, and the real Git boundary

This real GitHub portrait of Jujutsu creator Martin von Zweigbergk fits because the article is about a design wager, not about Git iconography. Jujutsu's appeal comes from maintainer-level choices about what should count as the repository's truth, what Git should still do, and where the boundary between those two layers belongs.[1][9]

The fastest way to misunderstand Jujutsu is to call it "Git with a better CLI" and stop there. That description is not false, but it hides the architectural shift that makes the tool interesting. Jujutsu does not mainly improve Git by rearranging commands. It improves the experience by changing what the user is asked to treat as real: the working copy becomes an ordinary commit, repository-changing actions are recorded in an operation log, and Git is reduced to a compatibility and storage layer instead of remaining the full conceptual model.[1][2][3][4]

That shift matters more in 2026 because the project is now active enough that teams can no longer dismiss it as a neat side experiment. As of 2026-04-10T23:04:07Z UTC, the GitHub API reports 27,740 stars, 1,001 forks, 1,040 open issues, and a most recent push at 2026-04-10T20:15:23Z for jj-vcs/jj.[7] Recent tagged releases show v0.40.0 on 2026-04-02, v0.39.0 on 2026-03-04, and v0.38.0 on 2026-02-05.[8] Those numbers do not prove the design is right. They do show a release line and maintainer cadence strong enough that the architecture deserves to be read on its own terms.

Image context: the cover uses Martin von Zweigbergk's real GitHub portrait rather than a Git logo, command screenshot, or abstract branching diagram. That choice fits because Jujutsu is not simply a new skin on familiar plumbing. It is a maintainer-led attempt to redraw version-control ergonomics around a different internal truth model.[1][9]

The working copy is not a buffer zone

The first design break is the working copy. Jujutsu's documentation says it plainly: unlike most version-control systems, the working-copy contents are automatically committed, and most jj commands will create or amend that working-copy revision when files have changed.[2] Added files are implicitly tracked by default, deleted files become implicitly untracked, and the system treats the working copy as one more commit in the graph instead of as a pre-commit staging area.[2][5]

That sounds like a user-interface trick until you notice how much it simplifies. Git's index exists partly as cache and partly as user-facing limbo. Jujutsu's comparison guide argues that this limbo does not need to be exposed at all: if you want part of the current state to become a commit, split or squash commits directly instead of shuffling content through an intermediate staging abstraction.[5] The architectural consequence is strong. There is one visible object class that matters most of the time: commits.[1][2][5]

This is also why Jujutsu feels friendlier to history-rewriting workflows than Git does. Once the working copy is already a commit, amending, splitting, or moving changes becomes graph editing rather than index choreography.[2][5] My inference from the docs and from Chris Krycho's long user report is that this is the real source of the "Git replacement" energy around Jujutsu. The simplification is conceptual before it is syntactic.[5][10]

The operation log is the real control surface

The second break is the operation log. Jujutsu records each repository-modifying action in an operation object, and each operation stores a snapshot of how the repo looked at the end of that action.[3] That snapshot, called a "view," includes bookmark positions, tags, Git refs in Git-backed repositories, the set of heads, and the working-copy commit for each workspace.[3] Because the operation graph is explicit, commands like jj undo, jj op revert, and jj op restore are not bolt-on recovery tricks. They are first-class consequences of the storage model.[3]

This is the most important architectural difference from Git's reflog culture. The Git comparison document says the operation log replaces reflogs, but the stronger claim is that it records whole-repo state transitions atomically rather than keeping separate per-ref histories.[3][5] That makes "what just happened?" a query against repository history, not an exercise in mentally stitching together branch movement, HEAD movement, and working-tree state from several partial ledgers.

The concurrency angle makes the same point even more clearly. The operation-log docs say the feature was created to allow lock-free concurrency, including concurrent jj commands on different machines sharing a distributed filesystem, as long as visibility ordering is preserved.[3] That is not a niche footnote. It reveals the level at which the tool is designed. Jujutsu is not only trying to make solo local commands pleasant. It is trying to make the repository state robust under overlapping edits and delayed reconciliation. That is a much more ambitious claim than "nicer Git UX."[1][3][6]

Git is the storage boundary, not the semantic boundary

The third break is where Git still matters. Jujutsu's README says the production-ready backend today is Git, and that this keeps the project compatible with Git-based tools and forges.[1] But the same README immediately draws a boundary that adopters should not miss: only commits and files are stored in Git, while bookmarks and other higher-level metadata live in custom storage outside Git.[1] The technical architecture document sharpens that point. The GitBackend stores commits in Git via gitoxide, keeps refs in a refs/jj/keep/ namespace so Git garbage collection does not delete commits still reachable from the operation log, and stores Jujutsu-specific metadata such as change IDs and predecessors under .jj/repo/store/extra/.[6]

That means Git compatibility in Jujutsu is real, but narrower than "everything works exactly like Git." The compatibility guide is admirably direct about the edges: branches are supported through bookmarks, authentication rides on Git for remote operations, merge commits are supported, and signed commits are supported, but .gitattributes, hooks, submodules, partial clones, git-worktree, sparse checkouts, and Git LFS are absent or partial in important ways.[4] The staging area is explicitly ignored, and colocated workspaces can mix git and jj commands, but Jujutsu usually leaves the Git repo in detached HEAD because it has no notion of a current branch in the Git sense.[4][5]

Bookmarks are the best example of the semantic split. Jujutsu describes them as named pointers like Git branches, but without an active or checked-out bookmark, and with tracking behavior that can map one local bookmark to matching names across remotes.[4][5] In other words, Git branch compatibility is preserved for collaboration, but the internal concept is no longer "the branch you are on." The conceptual center remains the commit graph plus Jujutsu's own metadata layer.[4][5][6]

What kind of team should care

The practical consequence is straightforward. Jujutsu is a serious fit for teams that want to keep Git hosting, pull requests, and ordinary remote collaboration while adopting a graph model that makes stacked changes, rewrites, and undo much less brittle.[1][3][4][5] If your pain comes from juggling the index, reflogs, detached HEAD states, and fragile rebases, Jujutsu is attacking the right layer of the problem.

The mismatch boundary is just as clear. If your workflow depends heavily on Git-native hooks, submodules, LFS, or other features the compatibility document still marks as unsupported or partial, then Jujutsu is not yet a drop-in semantic replacement.[4] The project is telling you to treat Git as an interoperability substrate, not as a promise that every Git-era assumption survives unchanged.

That is why the strongest one-line reading of Jujutsu is not "better Git." It is "a different repository truth model that still speaks Git where the ecosystem requires it." Once you read the project that way, the architecture becomes coherent: working-copy commits remove limbo, the operation log records whole-repo reality, and Git remains the transport and storage edge rather than the whole mental universe.[1][2][3][4][6]

cronfeed.work

Jujutsu in 2026: an architecture note on the operation log, working-copy commits, and the real Git boundary

The working copy is not a buffer zone

The operation log is the real control surface

Git is the storage boundary, not the semantic boundary

What kind of team should care

Sources

Recommended In oss