Jujutsu (jj)

1. Overview

Next-generation version control where even conflicts and rebases are recorded as deterministic, first-class mathematical states in an undoable local operation log.

Category: VCS & Core.

2. Version and scope assessed

Version assessed: Pinned source 531e8da8066271040b4b1e74ce17a8a941544cce.

4. Principle profile

5. Fundamental requirements

6. Evidence and verification

• E1: Jujutsu stores repository history locally and documents operation as a version-control system with command-line access. (source), confidence medium
• E2: The project documents GitHub and Git interoperability, supporting migration and coexistence with a widely readable repository format. (source), confidence medium
• E3: Git export invokes export_refs, not an operation-store archive. The separately inspected operation-log model retains repository views, workspace commits and operation metadata: Git export alone does not establish preservation of that full recovery history. (source), confidence medium
• E4: The tool operates on local repositories and does not require a hosted account for commits, history, or local inspection. (source), confidence medium
• E5: Undo restores a parent operation and refuses operations from another workspace unless explicitly overridden. Its implementation warns that undoing workspace removal restores the repository record but not the workspace directory. (source), confidence medium
• sovereignty: Local repositories and Git interoperability support user authority, with operational recovery still requiring evidence. (source), confidence medium
• longevity: E3 remains Not Verified for the existing essential-record scope. The methodology requires established E3 before a positive Longevity finding, so the earlier positive rating is withdrawn pending recovery evidence; source/format strengths are retained as facts, not graded as a failure. (source), confidence medium
• locality: The fundamental workflow is local and can be performed without a central service. (source), confidence medium
• transparency: E5 remains Not Verified. The methodology's Partially meets threshold requires demonstrated minimum oversight, so the earlier positive Transparency and Control finding is withdrawn rather than retained on the strength of one documented control. This is Not assessed, not Does not meet. (source), confidence medium
• E3: The retained operation-log model explains repository-state recovery, while git export exports refs rather than archiving the jj operation store. Independent interpretation and restoration of the preserved operation store, conflicts and workspace state remain unestablished. Invalid partial is replaced by Not Verified, not automatically converted to Pass or Fail. (source), confidence medium
• E5: The retained undo implementation provides real cross-workspace guards and explains that a removed workspace directory is not recreated by undo. However operation abandonment/garbage collection, colocated Git changes and actual correction/retention boundaries remain insufficiently covered. These source controls alone do not justify a whole-scope E5 Pass. (source), confidence medium

7. Migration and recovery

Native storage format: Append-only Operation Log + Git Backend.

Synchronization or runtime model: Git-compatible remotes / Native local.

Example export or inspection command (not verified against any particular version or data set): jj op log --limit 20

8. Architectural strengths

Established strengths and their scope are recorded in the evidence and assessment findings on this page.

9. Architectural limitations

• Pinned source inspection, not application execution.
• Conflicted-change export, actual operation-store copying, older-version recovery and abandon/garbage-collection behavior remain untested.

10. Assessment findings and remaining work

Verification scenario: Export Git-backed history and the operation log; test conflicting work and recovery after a clean installation.

What may invalidate an overconfident claim: Git interoperability does not imply that all jj operation history and conflict semantics are portable.

Documentation starting point: https://jj-vcs.github.io/jj/latest/

Evidence update: 23 October 2026

• Resolved: Undo restores a parent operation and refuses operations from another workspace unless explicitly overridden. Its implementation warns that undoing workspace removal restores the repository record but not the workspace directory. Source.
• Resolved: Git export invokes export_refs, not an operation-store archive. The separately inspected operation-log model retains repository views, workspace commits and operation metadata: Git export alone does not establish preservation of that full recovery history. Source.
• Open: Conflicted-change export, actual operation-store copying, older-version recovery and abandon/garbage-collection behavior remain untested.

Assessment follow-up: E3/E5 and their associated principle findings are now reconciled in rating batch 1 below. Earlier source/fixture observations remain valid within their stated scope; they are not themselves blanket Pass decisions.

Human-readable criteria: Can users retain complete history and metadata, operate and recover locally, migrate to another implementation, and understand the effects of synchronization or automation?

Rating reconciliation: 23 October 2026

Scope: The existing source-pinned application scope; no new application execution. Individual-custodian perspective. The existing broad preservation/workflow scope is retained, rather than narrowed to the one successfully inspected source path.

E3: The retained operation-log model explains repository-state recovery, while git export exports refs rather than archiving the jj operation store. Independent interpretation and restoration of the preserved operation store, conflicts and workspace state remain unestablished. Invalid partial is replaced by Not Verified, not automatically converted to Pass or Fail.

E5: The retained undo implementation provides real cross-workspace guards and explains that a removed workspace directory is not recreated by undo. However operation abandonment/garbage collection, colocated Git changes and actual correction/retention boundaries remain insufficiently covered. These source controls alone do not justify a whole-scope E5 Pass.

longevity: E3 remains Not Verified for the existing essential-record scope. The methodology requires established E3 before a positive Longevity finding, so the earlier positive rating is withdrawn pending recovery evidence; source/format strengths are retained as facts, not graded as a failure.

transparency: E5 remains Not Verified. The methodology’s Partially meets threshold requires demonstrated minimum oversight, so the earlier positive Transparency and Control finding is withdrawn rather than retained on the strength of one documented control. This is Not assessed, not Does not meet.

Evidence record: evidence/rating-reconciliation/batch-1/README.md and runtime-results.json. No target software was installed. Source inspections remain source inspections; no application-level recovery or destructive action was executed.

Remaining work: The existing open recovery and consequential-action scenarios remain pending; the individually explained E3/E5 blockers above determine the current Not Verified and Not assessed findings.

Rating reconciliation batch 1: E3 Not Verified; E5 Not Verified. Longevity Not assessed; Transparency and Control Not assessed. See the declared scope and reasons below; earlier bounded evidence findings remain recorded. The assessment procedure is described in the methodology.