Exploring Jujitsu (jj)

With the news that Firefox development is moving to git, and my own dislike of the git command line interface, I have a few months to figure out if there's a story that doesn't involve the git cli that can get me a comfortable development flow.

There's a few candidates, and each is going to take some time to correctly evaluate. Today, I have started evaluating Jujitsu, a git compatible version control system with some interesting properties.

  • The CLI is very mercurial inspired, and shares a lot of commonalities in supported processes (i.e anonymous head based development)
  • The default log is very similar to mozilla's hg wip
  • It considers the working directory to be a revision, which is an interesting policy.

Here's how I have started evaluating Jujitsu.

  1. First I created a new clone of unified which I called unified-git. Then, using the commands described by glandium in his recent blog post about the history of version control at mozilla I converted that repo to have a git object store in the background.
  2. I then installed Jujitsu. First I did cargo install binstall, then I did cargo cargo-binstall jj to get the binary of jj.
  3. I then made a co-located repository, by initializing jujitsu with the existing git repo: jj init --git-repo=.

After this, I played around, and managed to create a single commit which I have already landed (a comment fix, but still, it was a good exploration of workflow).

There is however, I believe a showstopper bug on my mac, which will prevent me from using jujitsu seriously on my local machine -- I will likely still investigate the potential on my linux build box however.

The bug is this one, and is caused by a poor interaction between jujitsu and insensitive file systems. It means that my working copy will always show changed files existing (at least on a gecko-dev derived repo), which makes a lot of the jujitsu magic and workflow hard.

Some notes from my exploration:

Speed:

This was gently disappointing. While the initial creation of the repo was fast (jj init took 1m11s on my M2 Macbook Pro), every operation by default does a snapshot of the repo state. Likely because of the aforementioned bug, this leads to surprising outcomes: for example, jj log is way slower than hg wip on the same machine (3.8s vs 2s). Of course, if you put jj log --ignore-working-copy, then it's way faster (0.6s), but I don't yet know if that's a usable working system.

Workflow

I was pretty frustrated by this, but in hindsight a lot of the issues came from having the working copy always seeming dirty. This needs more exploration.

  • jj split was quite nice. I was surprised to find out jj histedit doesn't yet exist
  • I couldn't figure out the jj equivalent of hg up . --clean -- this could be every history navigating tool, but because of the bug, it didn't feel like it.

Interaction with Mozilla tools

moz-phab didn't like the fact that my head was detached, and refused to deal with my commit. I had to use git to make a branch (for some reason a Jujitsu branch didn't seem to suffice). Even then, I'm used to moz-phab largely figuring out what commits to submit, but for some reason it really really struggled here. I'm not sure if that's a git problem or a Jujitsu one, but to submit my commit I had to give both ends of a commit range to have it actually do something.

Conclusion

I doubt this will be the last jujitsu post I write -- I'm very interested in trying it in a non-broken state; the fact that it's broken on my Mac however is going to really harm it's ability to become my default.

I've got some other tools I'd like to look into:

  • I've played with Sapling before, but because there's no backing git repo, it may not serve my purposes, as moz-phab wont work (push to try as well, I'll bet) but... maybe if I go the Steve Fink route and write my own phabricator submission tool... maybe it would work.
  • git-branchless looks right up my alley, and is the next took to be evaluated methinks.

Edited: Fixed the cargo-binstall install instruction (previously I said cargo install binstall, but that's an abandoned crate, not the one you want).