Git and Jujutsu: The next evolution in version control systems

Version control systems (VCS) are the silent enablers of every successful software delivery pipeline. For over 15 years, Git has reigned supreme as the de facto standard for tracking changes in code. However, as development workflows become increasingly complex, some limitations of Git have become apparent thus sparking interest in newer, more ergonomic alternatives.

Enter Jujutsu (often abbreviated as "jj"), a Git-compatible version control system designed to simplify common tasks, improve collaboration, and reduce the risk of costly errors.

This blog explores how Jujutsu compares to Git, why it’s gaining interest among forward-looking teams, and what makes it a strong contender in modern DevOps environments.

But first, let’s take a step back.

To understand Jujutsu’s value, it helps to revisit what makes Git so powerful and which are the areas where it falls short.

About Git

Git is a distributed version control system created by Linus Torvalds in 2005 for Linux kernel development. Today, it powers nearly every modern software project, with platforms like GitHub, GitLab, and Bitbucket built around it.

Key Git concepts

• Distributed architecture: Each developer has a complete copy of the entire repository history.
• Branching and merging: Lightweight branches enable parallel development and integration.
• Staging area: Acts as an intermediate zone between working directory and commit history.
• Commit hashes: Unique identifiers for each commit using SHA-1 hashing.
• Remote repositories: Central repositories that facilitate collaboration.

While Git is powerful, its design has some notable drawbacks, especially as workflows scale in complexity. A steep learning curve, uncommitted changes, rebase complexity, history rewriting and merge conflicts are among the prominent challenges that developers encounter.

What is Jujutsu?

Jujutsu is a Git-compatible VCS designed to overcome Git’s shortcomings, particularly around user experience, mutability, and conflict resolution. It aims to make daily workflows simpler and less error-prone, while remaining compatible with existing Git tooling.

Most importantly, Jujutsu is not a replacement for Git but rather an alternative interface to Git repositories, allowing teams to adopt it incrementally without disrupting their existing workflows.

What Jujutsu primarily brings to the table is:

• Git compatibility
• Simplified mental model
• Improved workflows
• Flexible history editing
• Better collaboration

Why Jujutsu?

While Git’s design is brilliant, it’s not always developer friendly. Its steep learning curve, verbose commands, and history manipulation quirks often lead to frustration, especially in fast-paced environments.

• Git’s power often comes at the cost of usability. Developers frequently run into issues like: Cryptic command-line interface (CLI)
• Confusing concepts like detached HEAD, index/staging area
• Complex rebasing and merging mechanisms
• Fragile conflict resolution process

Jujutsu was created by a Googler as an attempt to modernize version control. The philosophy behind Jujutsu is:

• Make the user interface more intuitive
• Allow safer, less error-prone versioning
• Provide better conflict handling
• Support mutable history for easier correction and clean-up

In short, Jujutsu is what Git could be if designed with today’s developer experience in mind - smarter, safer, and more human-centric.

Key features that set Jujutsu apart

• Immutable history model:  Every operation creates a new commit, reducing risk and making history easier to understand.
• Revsets: a powerful query language for selecting commits. This feature allows developers to perform complex operations on specific sets of commits easily.

  
  # Find all commits authored by Alice that touch Python files
  
  jj log -r "author(alice) & file(*.py)"
  

• Working copy as a commit:  In Jujutsu, the working copy is treated as a special commit, allowing all operations that work on commits to also work on the working copy. This unifies the conceptual model and simplifies many workflows.
• Multi-layered branches: Separates local, remote, and collaborative branches for clarity.
• Operation log: Easy ‘undo’ actions and review workflow history.
• Simplified Conflict Resolution:  Improved tools to manage and resolve complex conflicts including better visual indications and automatic resolutions.
• Git-Compatible: Works seamlessly with existing Git repositories.

Git and Jujutsu: At a glance

Workflow comparisons 

Let us compare some common Git workflows with their Jujutsu equivalents to highlight the differences and benefits.

Feature branch workflow

Git:

# Create and switch to a new feature branch

git checkout -b feature/new-feature

# Make changes and commit

git add .

git commit -m "Implement new feature"

 

# Push to remote

git push -u origin feature/new-feature

 

# Update with main branch changes

git checkout main

git pull

git checkout feature/new-feature

git rebase main

 

# Resolve conflicts if any

git add .

git rebase --continue

 

# Force push after rebase

git push --force-with-lease

Jujutsu:

[bash]

# Create a new change with description

jj new -m "Implement new feature"

 

# Create a branch pointing to this change

jj branch create feature/new-feature

 

# Make changes (they are automatically tracked)

# Update the current change description if needed

jj describe -m "Implement new feature - updated"

 

# Push to remote

jj git push --branch feature/new-feature

 

# Update with main branch changes

jj rebase -d main

 

# Resolve conflicts if any and continue

jj resolve

 

# Push updated branch

jj git push --branch feature/new-feature

Advantage Jujutsu:

• No need to explicitly stage changes before committing
• Rebasing is simpler and safer
• No need for force pushes
• Conflict resolution is more streamlined

Stashing workflow

Git:

[bash]

# Save uncommitted changes

git stash push -m "Work in progress"

 

# Switch branches

git checkout another-branch

 

# Do some work and commit

git add .

git commit -m "Work on another branch"

 

# Return to original branch

git checkout original-branch

 

# Apply stashed changes

git stash pop

Jujutsu:

[bash]

# Working copy is already a commit - create a new change

jj new -m "Work in progress"

 

# Switch to another branch

jj new main -m "Work on another branch"

 

# Do some work (changes are automatically tracked)

 

# Return to previous work

jj edit @--  # Edit the previous change

 

# Or checkout a specific change by ID

jj checkout <change-id>

Advantage Jujutsu:

• No need for a separate stash mechanism
• Working copy changes are always preserved
• Easier to manage multiple sets of changes

History editing workflow

Git:

[bash]

# Interactive rebase to edit history

git rebase -i HEAD~3

 

# In the editor, mark commits to edit with 'edit'

# For each commit marked as 'edit':

git commit --amend

git rebase --continue

 

# To reorder commits, change the order in the interactive editor

# Then continue the rebase

git rebase --continue

Jujutsu:

[bash]

# Edit a specific commit (3 commits back)

jj edit @---

 

# Make changes to files

# Update the commit

jj amend

 

# Return to the latest change

jj edit @

 

# Reorder commits using rebase

jj rebase -r @-- -d @---  # Move second-to-last commit after third-to-last

Benefits of Jujutsu:

• More intuitive history editing
• Less manual intervention required
• Safer operations with lower risk of mistakes

Code review workflow

Git:

[bash]

# Create a branch for review feedback

git checkout feature-branch

git checkout -b address-feedback

 

# Make changes based on feedback

git add .

git commit -m "Address feedback"

 

# Squash commits for clean history

git rebase -i HEAD~2

# In editor, change 'pick' to 'squash' for commits to combine

 

# Push updated branch

git push --force-with-lease origin feature-branch

Jujutsu:

[bash]

# Make changes based on review feedback

# (assuming you're on the feature branch)

jj describe -m "Address review feedback"

 

# Make the changes to files

# Amend the current change

jj amend

 

# To squash with previous commit

jj squash

 

# Push updated branch

jj git push --branch feature-branch

Advantage Jujutsu:

• Simpler commands for common operations
• Better visualization of history changes
• More intuitive squashing of commits

Cherry-picking workflow

Git:

[bash]

# Identify commit to cherry-pick

git log --oneline

 

# Switch to target branch

git checkout target-branch

 

# Cherry-pick the commit

git cherry-pick abc123def

 

# If conflicts occur

git add .

git cherry-pick --continue

 

# Push changes

git push origin target-branch

Jujutsu:

[bash]

# Identify commit to cherry-pick

jj log

 

# Switch to target branch

jj checkout target-branch

 

# Duplicate the commit (cherry-pick equivalent)

jj duplicate abc123def

 

# If conflicts occur, resolve them

jj resolve

 

# Push changes

jj git push --branch target-branch

Advantage Jujutsu:

• More intuitive representation of cherry-picked commits
• Better conflict resolution for cherry-picks
• Explicit indication that a commit is cherry-picked

Bisecting workflow

Git:

[bash]

# Start bisect process

git bisect start

 

# Mark current commit as bad

git bisect bad

 

# Mark a known good commit

git bisect good abc123def

 

# Git automatically checks out commits for testing

# After testing each commit:

git bisect good   # if the commit is good

# or

git bisect bad    # if the commit is bad

 

# After finding the faulty commit

git bisect reset

Jujutsu:

[bash]

# List commits in the range to bisect

jj log -r "abc123def..@"

 

# Create a new workspace for testing

jj workspace add ../bisect-workspace

 

# Switch to the workspace and test different commits

cd ../bisect-workspace

jj edit <commit-to-test>

 

# Test the commit, then try another

jj edit <another-commit-to-test>

 

# After finding the faulty commit, clean up

cd ../original-workspace

jj workspace forget ../bisect-workspace

Benefits of Jujutsu:

• Multiple workspaces allow parallel testing
• No need to constantly switch working copies
• Better visualization of the bisect process

Collaborative workflow with multiple contributors

Git:

[bash]

# Get latest changes from remote

git fetch origin

 

# See what others have done

git log --oneline origin/main..HEAD

 

# See incoming changes

git log --oneline HEAD..origin/main

 

# Integrate others' changes

git rebase origin/main

 

# If conflicts occur during rebase

git add .

git rebase --continue

 

# Incorporate specific changes from a colleague

git cherry-pick <colleague-commit-hash>

 

# Push your changes

git push origin main

Jujutsu:

[bash]

# Get latest changes

jj git fetch

 

# See what's new on remote

jj log -r "remote_branches()"

 

# See your local changes vs remote

jj log -r "main..@"

 

# Integrate remote changes

jj rebase -d main@origin

 

# If conflicts occur

jj resolve

 

# Duplicate specific changes from a colleague

jj duplicate <colleague-commit-id>

 

# Push your changes

jj git push --branch main

• Advantage Jujutsu:

• Better visibility of remote changes
• Simplified integration of others' work
• More intuitive handling of distributed workflows

Getting started with Jujutsu

Installation is simple (via Homebrew, winget, or source), and setup involves minimal configuration. Its command set is intuitive for Git users - just without the baggage of staging, complex rebasing, or stash juggling.
Here is some practical guidance on installation, configuration, and command equivalents for those ready to explore.

Installation

macOS

[bash]

brew install jj

 

Windows

[cmd]

winget install jujutsu --id jj-vcs.jj

From source

[bash]

git clone https://github.com/martinvonz/jj.git

cd jj

cargo install --path .

Refer official install and setup guide

Configuration

Create a .jjconfig.toml file in your home directory:

toml:

[user]

name = "Your Name"

email = "your.email@example.com"

 

[ui]

diff-editor = "vscode"

merge-tool = "vscode"

 

[aliases]

st = "status"

co = "checkout"

Basic commands

[bash]

# Initialize a new repository

jj init

 

# Or clone an existing Git repository

jj git clone https://github.com/example/repo.git

 

# Create a new change

jj new -m "Add new feature"

 

# Modify the current change

jj amend

 

# View status

jj status

 

# View history

jj log

 

# Compare changes

jj diff

 

# Push to Git remote

jj git push

 

Migration tips

For Git users transitioning to Jujutsu, here are some helpful equivalents:

Use cases 

Large-scale monorepos

Companies with large monorepos face unique challenges with version control. Jujutsu offers several advantages:

• Better performance with efficient handling of large repositories
• Improved visibility with clearer history visualization
• Enhanced collaboration with better merge conflict resolution
• Simplified workflows with reduction in complex Git commands

Cross-team collaboration

Enterprises with multiple teams working on shared codebases benefit from:

• Flexible branching: Easier management of feature branches
• Improved merge processes: Better resolution of conflicts
• Enhanced history editing: Cleaner commit history
• Compatibility with existing workflows: Incremental adoption possible

Known challenges with Jujutsu

Despite its promise, Jujutsu is still evolving. Limitations include:

• A smaller ecosystem compared to GitHub/GitLab.
• Differences in terminology and workflows require mental re-mapping.
• Limited IDE integrations.
• A learning curve for experienced Git users due to different mental models.
• Less community maturity compared to Git.

That said, its strong Git interoperability allows teams to experiment and gradually adopt features at their own pace.

Final thoughts

Jujutsu represents a significant evolution in version control systems, addressing many of Git's limitations while maintaining compatibility with Git repositories. While Git remains the dominant VCS and will continue to be widely used, Jujutsu offers a compelling alternative that simplifies many common workflows and reduces friction in the development process. As more developers experience these benefits, we may see a gradual shift toward Jujutsu or similar systems that build upon Git's foundation while addressing its pain points.

For teams considering Jujutsu, the good news is that adoption can be incremental. Developers can start using Jujutsu alongside Git on the same repositories, allowing for a gradual transition that minimizes disruption while maximizing benefits.

Whether you're a seasoned Git user looking for a more intuitive experience or a team leader seeking to improve developer productivity, Jujutsu is worth exploring as the next evolution in version control systems.

At InfoVision, we're constantly exploring such next-gen developer tools to improve engineering efficiency and software quality. If you're rethinking your DevOps strategy or looking to modernize your toolchain - let’s talk.

We’d be happy to share insights, adoption strategies, or even help you pilot emerging technologies like Jujutsu in your environment.

Connect with us at digital@infovision.com