Repository navigation
feat(tools/jujutsu): Jujutsu (jj) support for the local dev-loop #603
Description
Add tools/jujutsu/ so the local dev-loop skills can run on Jujutsu (jj) working copies. jj is Git-compatible at the storage layer but exposes a fundamentally different working model — no staging area, anonymous/auto-evolving changes, first-class conflict commits, and jj-style revsets instead of branches. The fix-workflow and code-review skills, which assume Git's branch/commit/git add model, would produce wrong or confusing steps on a jj repo even though the backing store is Git.
Capabilities to provide:
- Map the dev-loop primitives onto
jj:jj new/jj describefor commit,jj diff,jj log,jj bookmarkfor branch-equivalent hand-off - Translate the fix-workflow "create branch → commit → push" recipe into the
jjchange/bookmark model - Detect a
jjworking copy and route through this shim instead of rawgit - Reuse the VCS-capability abstraction from
tools/mercurial/
Why: jj adoption is growing fast among individual maintainers and at Google (its primary sponsor), and it's a common front-end over Git-hosted repos (GitHub/GitLab). Because it's Git-backed, an adopter can use jj locally while the forge stays GitHub — so this is low-risk, high-leverage support that several power-user maintainers would benefit from immediately.
Reference:
- Jujutsu: https://github.com/jj-vcs/jj
- Tutorial / mental model: https://jj-vcs.github.io/jj/latest/tutorial/
- Depends on the VCS abstraction from the Mercurial bridge issue
Activity
leninworld commentedon Oct 15, 2026
Hi @potiuk — I’d like to take this one. Could it be assigned to me?
Before writing code, I’d like to confirm three scope points:
Placement: I propose adding only a
JujutsuBackendundertools/vcs/src/magpie_vcs/, following the “Adding a backend” contract intools/vcs/README.md. It would be registered beforeGitBackend, because colocated Jujutsu/Git repositories contain both.jjand.git, anddetect_backendkeeps the first match when their roots are equal. I would not add a separatetools/jujutsu/directory or change the skills/fix-workflow in this PR. Is that the intended scope?Supported version: I propose requiring a Jujutsu release that supports
jj bookmarkandjj git push --bookmark, rather than the olderjj branchcommands. Should the project specify a particular minimumjjversion?Behavior and tests:
stage()would be a documented no-op because Jujutsu snapshots the working copy automatically. The other operations would map to the correspondingjj commit, bookmark creation, and bookmark push commands. Tests would cover detection—including a directory containing both.jjand.git—parsing without Jujutsu installed, and real temporary-repository round trips whenjjis available. Should CI installjjso the round-trip tests always run, or should those tests use the existing optional-tool skip pattern?