Jujutsu Two: A better experience

I've been working with Jujutsu the last month or so. It's actually been really nice. It's yet another reminder that, despite the version control system monoculture encouraged by GitHub, there's still innovation and interesting things happening in this space. It reaffirms my believe that plain git is really no longer where we should be aiming for as a community.

Last time I investigated Jujutsu I had some real show-stopping issues that prevented me from giving it a fair shake. This time I managed to get it set on my Linux machine such that it became my daily driver for the last month.

Experience

First and foremost, the ability to use your existing git-cinnabar enabled unified checkout as your repo, and seamlessly switch between git and jj is a pretty winning feature. Now, it turns out that Sapling experimentally is adding what they're calling dotgit support, but it's still experimental, whereas this is pretty core to Jujutsu.

It took me a little while to really internalize the power of a 'versioned working directory' workflow, but I've come to believe it's actually kind of wonderful.

Here's roughly what it looks like:

  1. jj new central "I would like to start working off of central". This produces a working directory with an associated "change id". Change IDs stay the same over the evolution of a working directory / commit.
  2. jj desc -m "Figure out how to frob the blob" Describe your working directory. This is totally optional.
  3. Do your work. The work is automatically checkpointed along the way any time you run a jj command.
  4. If you're interrupted and have to go work on something else, just go to that revision without worrying about losing work.
  5. When it's time to return to working on what you were, simply reopen the working directory with jj edit <change id>
  6. git pull use Cinnabar to pull in new changes.
  7. jj rebase -s working-dir-change-id -d central
  8. jj desc -m "Bug ABCD - Frobnicate the Blob with the Hasher r?freud" Update your description once you have a bug and a reviewer.
  9. jj commit No message edit here -- the description is used as the commit message

Unfortunately, it's here where we have awkwardness; moz-phab doesn't understand detached heads and freaks out when you try to submit. So at this point you have to create a branch, switch git to it, then submit the change. Almost certainly fixable, but we'll not ask the engineering effectiveness team for this.

Now, this is of course the happy path. There are certainly some brain-bending bits when you fall off of it. For example, the handling of conflicts is sort of strange: you edit a conflicted revision, then squash your resolution into the conflicted change, and it loses its conflict status. Dependent revisions and working directories are then rebased, which may have conflicts or not.

Some Setup Notes:

So the slowness I reported last time, everyone asked if I had set up watchman. I had not. So this time around, first thing:

jj config set --user core.fsmonitor "watchman"

Next: In order to make Jujutsu's log make any sense for Mozilla central, you have to teach it about what commits are 'immutable'. We had to do the same dance for Sapling too -- a side effect of not using the standard main branch name.

I put this into ~/.config/jj/config.toml, though it definitely belongs in the repo's .jj/repo/config.toml

[revset-aliases]
"immutable_heads()" = "central@origin | (central@origin.. & ~mine())"

Jujutsu vs Sapling?

Honestly, I have no idea where I'll land. If Sapling's dotgit support matures, it would be a really nice Mercurial replacement for people. But Jujutsu's versioned working directory is a legitimately interesting paradigmn.

I feel like there's a bit of a philosophical school thing going on here

  • Sapling feels like the crystallization of all the good ideas of Mercurial into a modern tool, suited for large scale development, supported by a large corporation.
  • Jujutsu feels like an evolution of git. Taking the position that today computers are fast, storage is fast, why not track more and be more helpful. Yet it still feels connected to the git heritage in a way that occasionally feels clunky. The developer works at Google, but I didn't get the feeling like jj was going to become the default for Googlers any time soon.

To paint a word picture... Sapling is an electric car with swooping lines, and Jujutsu is the Delorean from Back to the Future -- cobbled together with parts, but capable of amazing things.

Some Other Notes

  • The name of the tool is Jujutsu, not Jujitsu... which I have been thinking it was for 6+ months now 😨. My apologies to Martin von Zweigbergk, author of Jujutsu.
  • Use jj abandon to clean up your tree.
  • I find the default jj log to be quite noisy and a bit unpleasant.
    • Jujutsu's log formatting language is... very powerful (I don't get it all); but it has some cool built-in templates; try out jj log -T builtin_log_detailed or jj log -T builtin_log_oneline -- these defaults are defined here
  • Because your working directory is versioned, you can use jj obslog on it to explore the evolution of your working directory. This is super cool -- you can retrieve some code you deleted that you thought you didn't need, but turns out you did.
  • Jujitsu has a revset language that's similar but not identical to the one used in Mercurial and Sapling. For example, in mercurial to list my published commits, I might do hg log -r 'author(mgaudet) and public(). In jj I used jj log -r 'author(mgaudet) & ::central'.