This content originally appeared on Level Up Coding - Medium and was authored by Geek Nomad
How a Google engineer’s hobby project is reimagining version control with automatic commits, first-class conflicts, and a user-friendly approach that makes Git feel like yesterday’s technology
Imagine a world where version control just works. Where you never have to worry about staging files, where conflicts don’t stop your workflow, and where complex rebasing operations happen automatically without breaking a sweat. This isn’t a fantasy — it’s Jujutsu, a revolutionary version control system that’s quietly changing how developers think about managing their code.
The Story Behind Jujutsu
Jujutsu emerged from a simple yet profound observation: while Git revolutionized distributed version control, its user interface remains a significant barrier to productivity. Developers spend countless hours wrestling with staging areas, resolving conflicts, and recovering from failed rebases — time that could be better spent writing code.
The name itself has an interesting origin story. The command-line tool was first called jj simply because it's easy to type and remember. The project was then named "Jujutsu" to match the jj abbreviation—though it has nothing to do with the Japanese martial art or the popular anime series! This naming philosophy reflects the project's focus on simplicity and usability.
Important Note: While Martin works at Google, Jujutsu is not a Google product. It’s open-source software released under the Apache 2.0 license, developed as a hobby project that became a passion.
Understanding Git’s Fundamental Problems
To appreciate why Jujutsu represents such a significant leap forward, we need to understand the challenges that have plagued Git users for over a decade. Git was designed primarily as a content-addressable filesystem with a version control system built on top — a brilliant technical achievement, but one that prioritized power over usability.
The Staging Area Complexity
Git’s staging area, while powerful, creates a three-state model that confuses developers: modified files in the working directory, staged files in the index, and committed files in the repository. This complexity leads to common frustrations like forgetting to stage files before committing, accidentally committing partial changes, or losing work when switching branches without proper stashing.
Consider this common Git workflow nightmare:
# You're working on feature A git add file1.py # Oops, urgent bugfix needed - but you have unstaged changes git stash push -u -m "WIP feature A" git checkout main git checkout -b hotfix # Fix bug, commit, merge git checkout feature-A git stash pop # Conflict! Now you need to resolve merge conflicts in your stash
This scenario, familiar to most Git users, illustrates how Git’s model can interrupt flow and create unnecessary complexity.
The Conflict Resolution Nightmare
Git treats conflicts as exceptional states that must be resolved before any other operations can proceed. This creates a jarring experience where a simple rebase can leave you in a detached HEAD state, forcing you to understand Git’s internals just to get back to a working state.
Moreover, Git’s conflict markers are purely textual representations, which means that rebasing a conflict can create nested conflict markers — a situation that’s both confusing and difficult to resolve.
Branch Management Overhead
While Git’s branching model is powerful, it requires significant mental overhead. Developers must name every branch, remember to clean up merged branches, and navigate complex merge histories. The need to constantly create, name, and manage branches can slow down exploratory work and quick experiments.
What Makes Jujutsu Different?
At its core, Jujutsu addresses the fundamental pain points that have plagued Git users for years. While Git revolutionized version control, its user interface remains notoriously complex, forcing developers to learn arcane commands and navigate confusing states.
The Working Copy Revolution
The most radical difference in Jujutsu is that your working copy is always a commit. Unlike Git’s staging area model, every change you make is automatically recorded in the current commit and amended with each subsequent change. This eliminates the mental overhead of remembering to stage files and removes the possibility of losing work.
Here’s a practical example of how this changes your workflow. In Git, you might work like this:
# Traditional Git workflow git checkout -b feature-branch # Edit files git add file1.py file2.py git commit -m "Add initial feature implementation" # More edits git add file1.py git commit -m "Fix bug in feature" # Even more edits git add --all git commit -m "Add tests"
In Jujutsu, the same work looks like this:
# Jujutsu workflow jj new -m "Add initial feature implementation" # Edit files - they're automatically tracked jj new -m "Fix bug in feature" # More edits - automatically in this commit jj new -m "Add tests" # Final edits - automatically tracked
Notice how you never need to remember to stage files, and switching between different pieces of work doesn’t require complex stashing operations.
The Change vs. Commit Philosophy
One of Jujutsu’s most important conceptual innovations is the distinction between changes and commits. In Git, a commit has a fixed identity — its SHA hash changes if you modify anything about it. In Jujutsu, a change represents a unit of work that maintains its identity even as it evolves.
This distinction enables powerful workflows. You can modify a change from three commits ago, and all descendant commits will be automatically rebased without changing their change IDs. This makes it trivial to fix bugs in earlier commits or reorganize your work history.
# Fix a bug in an earlier change jj edit abc123 # Go to the change with ID abc123 # Make your fix - descendants will auto-rebase jj edit @ # Return to your current work
Anonymous Branches: Freedom from Naming
Jujutsu embraces “anonymous branches” by default, borrowing this concept from Mercurial. You don’t need to name every small change or experimental branch. Instead, changes are identified by their descriptions and change IDs, which are much more meaningful than arbitrary branch names like “fix-thing-2” or “temp-branch-do-not-merge”.
This approach is particularly powerful for rapid prototyping or when exploring multiple implementation approaches. You can create parallel lines of development without the overhead of branch management:
jj new -m "Try approach A" # Work on approach A jj new @- -m "Try approach B" # Create sibling change # Work on approach B jj new @- -m "Try approach C" # Another sibling # Later, easily compare or merge the best parts
First-Class Conflicts: The Game Changer
Perhaps the most revolutionary aspect of Jujutsu is its treatment of conflicts as first-class objects. This represents a fundamental shift from how every other version control system handles conflicts.
In traditional systems like Git, conflicts are errors that halt your progress:
# Git conflict scenario git rebase main # CONFLICT: Automatic merge failed; fix conflicts and then commit # You're now stuck until you resolve everything
In Jujutsu, conflicts are just another state that can be managed:
# Jujutsu conflict scenario jj rebase -d main # Conflicts detected, but operation completes successfully jj log # Shows conflicted commits clearly marked jj new -m "Continue other work" # You can keep working # Resolve conflicts when you're ready
This approach has profound implications. You can:
- Postpone resolution: Deal with conflicts when you have time and context
- Collaborate on conflicts: Hand off tricky merges to team members
- Rebase conflicted commits: Move conflicted changes around without creating nested conflicts
- Work on top of conflicts: Continue development even with unresolved conflicts in your history
The technical implementation is elegant: instead of storing textual conflict markers, Jujutsu maintains a logical representation of conflicting trees. This means rebasing a conflicted commit doesn’t create the dreaded “nested conflict markers” that can appear in Git.
The Power of Revsets
Jujutsu incorporates Mercurial’s powerful revset language for selecting commits, making complex queries intuitive and readable. While Git requires you to remember obscure syntax like HEAD~3..HEAD^2, Jujutsu uses natural expressions:
# Git: Show commits in branch but not in main git log main..feature-branch # Jujutsu: Much more readable jj log -r "feature-branch ~ main" # Show all your commits from the last week jj log -r "mine() & after:'1 week ago'" # Show all commits that modified a specific file jj log -r "file('src/main.py')"
This expressiveness extends to all operations. You can rebase, abandon, or modify sets of commits using the same intuitive syntax.
Operation Log: Time Travel for Version Control
Every operation in Jujutsu is recorded in an operation log, creating a meta-history of how your repository evolved. This is like Git’s reflog, but much more comprehensive and reliable.
# See what you've been doing jj op log # Made a mistake? Just undo it jj undo # Want to go back to yesterday's state? jj op restore <operation-id>
This feature removes the fear factor from version control. You can experiment freely, knowing that any mistake can be easily undone. Unlike Git’s reflog, which can be garbage collected and is often incomplete, Jujutsu’s operation log is comprehensive and permanent.
Key Features That Set Jujutsu Apart:
- No Staging Area: Changes are automatically tracked without git add
- Anonymous Branches: Work without naming every small change
- Operation Log & Undo: Every operation is recorded and can be undone
- Powerful Revsets: Query language inspired by Mercurial for selecting commits
- Safe Concurrent Operations: Works safely with Dropbox, rsync, and distributed filesystems
- Git Compatibility: Use existing Git repositories and tools
Advanced Workflows Made Simple
Jujutsu’s design philosophy shines when handling complex scenarios that are painful in Git. Let’s explore some advanced workflows that become natural in Jujutsu.
Parallel Development
Working on multiple features simultaneously is a common need, but Git makes this awkward with its branch-centric model. Jujutsu’s anonymous branches make parallel development effortless:
# Start multiple parallel features jj new main -m "Add user authentication" # Work on auth feature jj new main -m "Improve database performance" # Work on performance feature jj new main -m "Update UI components" # Work on UI updates # See all parallel work jj log
You can easily switch between these parallel efforts, and Jujutsu will show you a clear visual representation of your work-in-progress branches.
Incremental Code Review
Modern development often involves iterative code review, where reviewers request changes that need to be incorporated into specific commits. Git’s approach typically involves force-pushing, which breaks review tooling and creates confusion.
Jujutsu’s stable change IDs make this process smooth:
# After code review feedback jj edit abc123 # Go to the specific change that needs updates # Make the requested changes # Change ID remains stable, but descendants auto-rebase jj git push # Push updates without force-push
Stack Management
Many developers work with “stacks” of related commits that build on each other. Managing these stacks in Git requires careful attention to rebase operations and branch management. Jujutsu makes stack management natural:
# Create a stack of related changes jj new main -m "Add base API framework" jj new -m "Add authentication middleware" jj new -m "Add user endpoints" jj new -m "Add admin endpoints" # Need to modify the base framework? jj edit <base-change-id> # Make changes - entire stack rebases automatically
Real-World Migration Stories
Developers who have made the switch to Jujutsu consistently report similar experiences: initial skepticism followed by gradual adoption and eventual enthusiasm. Here are some common patterns in their migration stories.
The “Aha!” Moment
Most developers experience a breakthrough moment when they realize they can stop worrying about repository state. As one user described: “I spent years being careful not to break my Git repository. With Jujutsu, I experiment freely because I know I can always undo any operation.”
Productivity Gains
Users report significant productivity improvements, particularly in areas that were previously friction points:
- Context Switching: No more stashing and unstashing when switching between tasks
- History Editing: Fixing earlier commits becomes trivial instead of requiring complex rebases
- Conflict Resolution: Conflicts can be dealt with when convenient rather than immediately
- Experimentation: Creating experimental branches and changes has zero overhead
Team Adoption Patterns
Interestingly, because of Jujutsu’s Git compatibility, individuals can adopt it without requiring team-wide changes. Many users report using Jujutsu locally while their teams continue using Git, creating a smooth path for gradual adoption.
Jujutsu vs Git: A Comprehensive Comparison
Let’s examine how common operations compare between the two systems, highlighting not just the syntax differences but the conceptual improvements:
OperationGitJujutsuStart workinggit checkout -b featurejj new -m "feature"Check statusgit statusjj statusView historygit log --oneline --graphjj logCommit changesgit add -A && git commit -m "msg"jj describe -m "msg"Amend last commitgit add -A && git commit --amendJust edit files (automatic)Switch to another branchgit stash && git checkout otherjj edit otherUndo last operationgit reflog && git resetjj undoCreate partial commitgit add -p && git commit -m "msg"jj split -iFix commit 3 changes backgit rebase -i HEAD~3 (complex)jj edit <change-id> (simple)View repository stategit log --graph --all --decoratejj logWork on multiple featuresMultiple branches + complex switchingAnonymous changes + simple switching
Deep Dive: Technical Innovations
Beyond user experience improvements, Jujutsu introduces several technical innovations that enable its superior workflow.
Abstract Storage Layer
Unlike most version control systems that tightly couple their user interface to their storage model, Jujutsu separates these concerns. This architectural decision allows Jujutsu to use Git as a storage backend while presenting a completely different user model.
This abstraction has practical benefits: Jujutsu can potentially support multiple storage backends, making it adaptable to different organizational needs. Google, for instance, is exploring using Jujutsu with their internal cloud-based storage systems.
Safe Concurrent Operations
Jujutsu is designed to be safe under concurrent access scenarios that would corrupt Git repositories. You can safely store Jujutsu repositories in Dropbox, sync them with rsync, or access them from multiple machines simultaneously without fear of corruption.
This safety comes from Jujutsu’s conflict-aware design — instead of corrupting the repository, concurrent operations simply create conflicts that can be resolved later.
Content-Addressed Storage with User-Friendly IDs
While Jujutsu uses content-addressed storage like Git, it presents human-friendly identifiers to users. Change IDs are short, pronounceable strings that remain stable even as the underlying commits change. This makes it easy to refer to specific changes in conversations and documentation.
Performance Characteristics
Jujutsu is implemented in Rust and designed for performance from the ground up. While it adds a layer of abstraction over Git, users report that day-to-day operations feel snappy and responsive.
The automatic rebasing operations, which might seem expensive, are optimized to be fast for typical use cases. The system is also designed to scale to very large repositories — a necessity given Google’s involvement and their massive monorepo requirements.
Memory and Disk Usage
When using the Git backend, Jujutsu repositories take up roughly the same disk space as equivalent Git repositories, since the actual content is stored in Git format. The additional Jujutsu metadata is minimal.
Memory usage during operations is carefully managed, with lazy loading of commit information to support large repositories efficiently.
Real-World Benefits
Users consistently report that Jujutsu’s mental model is much simpler than Git’s. Everything is a revision — no staging area, no stash, just commits that you can freely edit and rearrange. As one developer put it: “If using the Git CLI is like bumping into a wall with your shoulder at full speed, using jj is like getting a gentle and pleasant back massage.”
Fearless Experimentation
The combination of the operation log and undo functionality creates an environment where developers feel safe to experiment. You can merge branches, create conflicts, resolve them, mess up, and simply run jj undo to go back as if nothing happened.
Better Code Review Workflows
Jujutsu’s stable change IDs and automatic rebasing create superior code review experiences. Reviewers can refer to specific changes by their stable IDs, and authors can update individual commits in a stack without disrupting the review process.
This is particularly valuable in organizations that practice stack-based development, where related changes are submitted as a series of commits rather than monolithic pull requests.
Improved Debugging and Archaeology
The operation log provides unprecedented visibility into how a repository evolved. When debugging issues or understanding how certain changes were introduced, you can examine not just what changed, but how the repository state evolved over time.
This meta-history is particularly valuable when working on complex changes that involved multiple rebases, splits, or squashes — operations that obscure history in traditional systems.
Getting Started with Jujutsu
The beauty of Jujutsu is that you can start using it today without disrupting your team’s workflow. Thanks to its Git compatibility, you can experiment with existing Git repositories.
Installation Options
Jujutsu can be installed through various package managers or compiled from source. Pre-built binaries are available for Windows, Mac, and Linux.
Colocated Mode: The Perfect Starting Point
The easiest way to try Jujutsu is through “colocated mode,” which allows you to use both Jujutsu and Git in the same repository:
# Initialize in an existing Git repo jj git init --colocate # Or clone a new repo jj git clone --colocate https://github.com/user/repo.git
This approach lets you experiment with Jujutsu while keeping the option to fall back to Git commands when needed. Your .git directory stays in place, and your editor won't even know anything changed.
Basic Setup and Configuration
After installation, you’ll want to configure your identity and potentially customize the interface:
# Configure identity jj config set --user user.name "Your Name" jj config set --user user.email "your.email@example.com" # Set up shell completion (bash example) echo 'source <(jj util completion bash)' >> ~/.bashrc # Configure your preferred diff/merge tools jj config set --user ui.diff.tool "vimdiff" jj config set --user ui.merge.tool "vimdiff"
Understanding the Interface
Jujutsu’s output is designed to be more informative than Git’s. The jj log command shows a visual representation of your repository structure with color-coded information about change states, conflicts, and relationships.
Key symbols to understand:
- @ - Your current working copy
- ○ - Regular commits
- × - Conflicted commits
- ~ - Hidden/obsolete commits
Common Workflow Patterns
Here are some workflow patterns that new users find helpful:
# Start a new piece of work jj new -m "Implement user registration" # Need to quickly fix something else? jj new @- -m "Fix typo in documentation" # Fix the typo, then return to your main work jj edit <registration-change-id> # Want to split your current change? jj split -i # Interactive split interface # Made a mistake? Undo it jj undo # Need to see what you did recently? jj op log --limit 10
Integrating with Existing Tools
Since Jujutsu maintains a Git repository in the background, most Git-based tools continue to work. Your IDE’s Git integration, continuous integration systems, and deployment scripts should work without modification.
However, be aware that some operations (like viewing conflicted files) may appear strange to Git-based tools, since they don’t understand Jujutsu’s conflict representation.
The Learning Curve and Common Pitfalls
While Jujutsu’s concepts are simpler than Git’s, there is still a learning curve — especially for experienced Git users who need to unlearn certain habits.
Mental Model Adjustments
The biggest adjustment is understanding that you don’t need to explicitly commit changes. Many Git users instinctively look for a jj commit command and feel uncomfortable when they can't find one.
Another common confusion is the relationship between changes and commits. In Git, these concepts are identical, but Jujutsu’s distinction between them enables much of its power.
Command Mapping Challenges
Experienced Git users often try to map Jujutsu commands directly to Git equivalents, but this approach can be limiting. Instead of git add -p && git commit, you need to think in terms of jj split to break apart changes.
Typical Learning Timeline
Most developers report a predictable learning progression:
- Day 1: Confusion and frequent consultation of documentation
- Week 1: Basic operations become natural, occasional Git habits resurface
- Month 1: Comfort with advanced operations, appreciation for the design
- Month 3: Difficulty returning to Git, evangelizing to colleagues
Current Limitations and Future Development
As an experimental system under active development, Jujutsu doesn’t yet support all of Git’s features. It’s important to understand these limitations before making the switch.
Missing Git Features
Notable features that Jujutsu doesn’t currently support include:
- Git submodules: No equivalent functionality exists yet
- Partial and shallow clones: Important for very large repositories
- Multiple work trees: Git’s worktree functionality
- Signed commits: GPG signing support is not implemented
- Git LFS: Large file storage integration
- Built-in bisect: Binary search debugging tool
- Advanced hooks: Comprehensive Git hook system
Ecosystem Maturity
While Jujutsu’s Git compatibility means most Git-based tools work, the native Jujutsu ecosystem is still developing. Areas where this is most noticeable include:
- IDE Integration: Limited compared to Git’s extensive tool support
- GUI Tools: Fewer graphical interfaces available
- Educational Resources: Smaller community means fewer tutorials and guides
- Advanced Integrations: Some specialized Git workflows may not have Jujutsu equivalents
Development Roadmap
The Jujutsu project maintains active development with regular releases. Recent versions have added features like file annotation (equivalent to git blame) and improved conflict resolution interfaces. The development team is responsive to community feedback and consistently improves both functionality and user experience.
Google’s involvement suggests a long-term commitment to the project, particularly as they explore using Jujutsu with their internal infrastructure. This provides confidence in the project’s future sustainability.
Community, Resources, and Tooling
Despite being a relatively new project, Jujutsu has cultivated an active and helpful community. The project maintains several channels for support and discussion:
Community Channels
- Discord: Active real-time chat with core developers
- GitHub Discussions: Longer-form questions and feature discussions
- IRC: #jujutsu on Libera Chat (bridged to Discord)
Learning Resources
Several excellent resources exist for learning Jujutsu:
- Official Documentation: Comprehensive and well-maintained
- Steve Klabnik’s Tutorial: Excellent introduction from a respected developer
- Interactive Help: jj help provides contextual assistance
- Community Blogs: Growing collection of real-world usage experiences
Tooling Ecosystem
The tooling ecosystem is expanding rapidly:
- VisualJJ: Visual Studio Code extension providing GUI operations
- jj-fzf: Interactive terminal interface using fuzzy finding
- jujutsu.el: Emacs interface inspired by the excellent Magit
- Various templates: Custom log formats and workflow configurations
Integration Examples
Many users have shared their integration setups, including:
- Shell aliases: Shortcuts for common operations
- Custom templates: Personalized log output formats
- Workflow scripts: Automation for repetitive tasks
- CI/CD integration: Using Jujutsu in automated pipelines
Why You Should Consider Jujutsu
Jujutsu represents a fundamental rethinking of version control user experience. While Git solved the technical challenges of distributed version control, Jujutsu solves the human challenges of using version control effectively.
Here’s why it matters:
- Reduced Cognitive Load: Simpler mental models mean more focus on actual work
- Lower Risk: Comprehensive undo functionality removes fear of making mistakes
- Better Workflows: Automatic operations reduce manual intervention
- Future-Ready: Designed for scale and modern development practices
The Verdict
Jujutsu isn’t just another Git wrapper — it’s a reimagining of what version control could be if designed today with modern understanding of developer workflows. While it’s still experimental, its core ideas are solid and its Git compatibility makes it a low-risk way to significantly improve your development experience.
Whether you’re a Git novice frustrated by complex workflows or an expert tired of working around Git’s limitations, Jujutsu offers a compelling alternative. It might just be the version control system you’ve been waiting for.
Ready to try Jujutsu? Visit the official documentation to get started, or check out Steve Klabnik’s excellent tutorial for a hands-on introduction.
Jujutsu VCS: A Git-Compatible Revolution in Version Control was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Geek Nomad
Geek Nomad | Sciencx (2025-09-03T15:02:51+00:00) Jujutsu VCS: A Git-Compatible Revolution in Version Control. Retrieved from https://www.scien.cx/2025/09/03/jujutsu-vcs-a-git-compatible-revolution-in-version-control/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.