Preliminary thoughts on the Jujutsu VCS

Over the past few months, a small group of us at work have been experimenting with the Jujutsu Version Control System. For many of us, it has managed to replace Git in our day-to-day workflows, and has integrated very well into existing internal processes.

What is Jujutsu?

Jujutsu (JJ) is a modern Version Control System that abstracts user-facing operations from its underlying storage backends.

This means that the user only needs to worry about the “JJ way of doing things”, and doesn’t need to worry about what’s happening under the hood to allow them to interface with other VCSes.

..and yes, you heard that right, JJ interfaces with other VCSes. At work, we use Git repositories for everything, so those of us that use JJ locally have it configured to run in “co-located git mode”, pushing and pulling from our internal Git servers like normal, while we are treating the repos like JJ repos.

How Jujutsu compares to Git

This is a tricky thing to describe.

I’ve found that there are generally three types of Git users.

• Push a ton of tiny commits, where each commit may or may not build
• Everything is a waterfall
• Everything behaves like a mailing list

At work, teams generally get to pick between the second and third option (mixed with some monorepo shenanigans), but a common theme everywhere is: every single commit is a discrete feature or patch.

This means that no matter the merge strategy, you’ll find large well-documented commits that all individually can be built into a valid binary or system state.

In this environment, I’d say that Jujutsu is very similar to Git. Where I’d do some git rebase -i and squashing in Git, I can create a single “change” in JJ to produce the same types of commits/patches.

Now, if you work in an environment where you do real merges (instead of squashes and rebases), I have a feeling JJ will feel weird. I currently do not have enough experience using JJ in such a setting to comment on this though.

A very basic Jujutsu workflow

Interacting with a git repo through Jujutsu generally looks something like this:

# Hopping into an existing git repo
cd my-repo

# Getting Jujutsu to play nice with git
jj git init --colocate

Next, I shall start a new change off of the “master” branch

jj new master

Then, I can make some changes, and “describe” what I’ve done

# ...Some files have been changed...

# Describe the change
# NOTE: This could be done before starting work if desired
jj desc

# Push the change to the remote for review
# Creates a specially named git branch for this change that lives for the duration of review
jj git push -c @

Note the -c @. JJ has a very rich system for selecting and grouping changes (called revsets) for cases where you need to operate on more than one change at once.

There are of course a ton of other operations and commands available, but to be honest, 90% of my interactions with JJ are the commands listed above (along with jj git fetch and jj undo 🙄).

My thoughts so far

I’ve been quite enjoying this adventure into a new VCS.

At times it reminds me of when I first learned to use Git, and that is a time I’d prefer to not re-live, but sometimes you have to suffer a little in the name of learning a new workflow.

Would I recommend JJ to a friend? Yes, but only if they are familiar with Git’s pluming.

Will I go back to using Git directly? Probably not.