Git is life!

Or is it?

In my career I’ve worked with quite a few VCS systems. I started with CVS (it was awful) and then happily migrated to SVN when I saw it removed the major pain points I had with CVS (binary handling streamlined as any other asset for example).

Although git started in 2005 I only became aware of it around 2012. At that time the pain of not being able to have branches locally with SVN was really becoming an issue for my workflow. I liked to experiment and having to create branches on the remote for this was just too annoying (and noisy) for my team so I had to deal with having a lot of mess around in my filesystem.

So when I saw git had git-svn I immediately jumped ship and went into the deep waters of learning a new VCS with a different paradigm. The first approach was quite difficult and git is quite notorious for its sometimes cumbersome CLI and developer experience. Back in the day the experience was much more cryptic than it is nowadays and it made switching quite daunting. Having that bridge meant I could learn it the hard way (®) though. I like learning by practicing and experimenting so that was perfect.

It became quickly clear that I would ditch svn very fast given the flexibility git provided. I’ve always loved being so free and happily took the trade-off of having to deal with the various strategies I encountered during my various experiences.

Coming from legacy systems like cvs and svn meant git looked absolutely paradisiac in comparison and so I settled for that for a long time. There always has been a bit of friction on some areas but nothing compared and the hegemony of the tool meant switching would be too complex anyways.

That is until I became aware of Jujutsu.

Just like git did with git-svn, jujutsu supports a colocate mode that will use git as a backend and allow using jj at the same time. This greatly helps the transition because you can start working with the new tool while still going back to the one you know best seamlessly for stuff you don’t know how to do yet.

Birds of paradise

At first glance this isn’t too different from git. It tracks changes in commits, allows collaboration and high level of history edition/adjustments with a few commands. The first meaningful differences we can spot while learning is how there are a lot fewer commands to know about.

You want to commit? jj commit has got you.
You want to squash? jj squash has got you.
A rebase perhaps? jj rebase is there for you.

On surface, it is as simple as that. Jujutsu has no support for branches though, not as you’d expect on a git sense at least. It supports this through what it calls bookmarks which can be seen at first as a git tag even though they differ (and jj doesn’t support tags actually as of now, it’s under active development).

Because every revision has descendants and ancestors we can still treat everything like a graph and have “branches” as we would with any git repo.

But the selling point for jj is not being able to do the same. You can see what the usual points are on this and they have a page up on the topic on their documentation. Here are the ones I would say made me want to switch and helped me stick with the learning:

No staging area

No more dealing with what’s staged or not. Jujutsu automatically tracks every file and every change. Everything is staged by default and will be included in the currently selected revision (think @HEAD from git terminology).

This is maybe what is the most surprising at first and it feels quite uncomfortable to begin with. As my experience and understanding of the tool grew it became second nature and I now wouldn’t see myself living without this.

Descendants are automatically rebased

Unlike in git, you can “checkout” (git terminology) any revision and make edits in it. Once done, all descendants will automatically include said change(s). In practice it means rebasing just became a very simple operation you don’t have to dance around anymore. It just works and jujutsu doesn’t get in the way. It will handle the heavy lifting for you.

Conflicts are first class citizens

Which brings us to this point. If you can edit anything at any point in time (unless the revisions are marked as immutable), you are bound to face the dreaded conflicts at some point. Unlike in git, a conflict isn’t a showstopper. Jujutsu will simply mark any revision in conflict as such and you can go and fix it at any moment and when you do every descendant will automatically benefit from the fix.

This means you can safely rebase your work on top of new changes and you won’t be blocked halfway upon having conflicts. The rebase will carry through completely and you can either keep working if you want or fix the conflict right away so you don’t have to come back to it later.

Gone are the days of rebasing X commits on top of new changes from main and having to git rebase --reset in the middle of a conflict resolution because something is messed up and you have to start again from scratch.

Easy to experiment

Want to do something but you’re not sure how? Do it.

Worst case scenario it didn’t work out and you can simply jj undo to get back to the previous state. This is much much simpler to deal with than git reflog and makes learning and fixing situations a breeze.

How to learn?

I would recommend the two obvious sources:

• https://docs.jj-vcs.dev/latest/tutorial/ (official documentation)
• https://steveklabnik.github.io/jujutsu-tutorial/ (Alternative introduction by a now-contributor)

Both are quite excellent although maybe the second one is more hands on approach.

The main thing here is just to start. Colocating with a git repository will allow a smooth transition and I’d recommend just starting with simple commits and branching to get a feel for it.

From there, situations will arise naturally and you’ll learn the missing elements as they become necessary.