“Jujutsu (jj) is a version control system with a significantly simplified mental model and command-line interface compared to Git, without sacrificing expressibility or power (in fact, you could argue Jujutsu is more powerful). Stacked-diff workflows, seamless rebases, and ephemeral revisions are all natural with jj […]”
Part 2 of the series is out and is here.
Finally I can become a Jujutsu sorcerer IRL
So this is a git frontend I guess?
Yeah, sort of. It can be used e.g. instead of command-line git commands, or also be intermixed with them. Pushing a branch to a git server works as normal “git push” (needed in older versions with complex vpn/ssh configurations).
Has also still limitations remaining - no git submodule support. But it has work trees.
I’d argue work trees are largely better than submodules in most situations anyhow.
Edit: oh I confused subtrees and worktree.
More shortcomings of jujutsu:
Some things that are also missing are signing commits and such, but again one can use git for this.
Also, git servers and tools like github, gerrit etc. don’t know about jujutsu’s change ids, so the advantages are kept local. But this is changing, the tools are adding this metadata.
Also, one can sync up jj repos with rsync, which transmits the change ids.
gitk shows many temporary commits which is distracting.
It obsoletes Emacs Magit, which means vim is the better choice for editing commit messages, which means you see yourself morphing into a vim user. Or maybe emacsclient.
Building jujutsu from source requires a fairly up-to-date Rust environment. (One can download a binary that is statically linked with musl from github but I hate downloading binaries). Debian stable has not even an out-dated version. Building it under Guix’s cargo took me some tries.
Seeing the list of dependencies makes one wonder whether it was written in node/js.
The mental model is fascinatingly simple. It is: You have a directed acyclical graph (DAG) of “changes”, which are often drawn like this.. Then, you have a small set of commands that operate on that graph, e.g. adding changes, fusing two into one or splitting up one into two, adding nodes that have more than one parents, rebasing single nodes or a series of changes. And changing the content of these nodes in the commit graph is almost always done with the normal source code editor - everything one saves becomes already part of the graph when the next jj command is run.
Jujutsu does not use branches much because you are focused on the nodes in the commit graph. And instead of giving every of them manually a name, they are identified with change IDs. Branches are called “bookmarks”, they can be attached to a commit graph node, and are used mostly for collaboration.
And when you push that graph of mutable changes to remote, they become a graph of normal commits that should not be changed under normal circumstances (because they are shared history now).
Jujutsu does not use branches much because you are focused on the nodes in the commit graph. And instead of giving every of them manually a name, they are identified with change IDs.
This is… unforgivably obnoxious. What’s the point of this? That’s like saying “Instead of giving every directory a name manually you identify them by inode.” The entire point of branches is to have a name that has meaning to me that I can use to refer to work I’m doing.
As soon as you edit a file, the changes will be included in whatever revision you’re currently editing—there’s no separate staging area in Jujutsu.
I create log files of runs, temporary helper scripts, build output, etc. in my working copy all the time. And this thing is going to “save me the burden” of having to add files manually by just adding… everything it sees.
You’ll have noticed that at no point so far did we ever think about creating a branch. That’s because Jujutsu’s relationship to branches is a bit different to Git’s—they’re just pointers that you move around so they point to whichever revision you want them to at a given time.
“Simpler” apparently means I get to do a lot more book-keeping than when I use git.
Jj’s closest equivalent of branches are bookmarks, but they don’t auto update when you pull from a remote. I wish it was more like a git branch in that sense.
However, editing past commits and reorganizing the tree is MUCH easier in jj. It feels like the commands are more in line with what I want to do rather than having to figure out the specific set of git commands to do what I want.
I did find the “adding EVERYTHING” behavior to be annoying initially. My workaround was to create a local folder and add it to git ignore and push all those temp files there.
YMMV but I’ve found it much easier to manage complex workflows with jj compared to git.
YMMV but I’ve found it much easier to manage complex workflows with jj compared
It is no secret that git’s interface is a bit too complex - even XKCD has made fun of it.
But what is amusing is that people now have a kind of Stockholm Syndrome, and plain refuse to believe there could be something better.
(Perhaps motivated by the long list of half-assed helper interfaces and GUIs which just were hapless trying to hide the sprawling complexity).
Telling people they have Stockholm syndrome is not a good way to convince them to change their behavior. Present the pros, be honest about the cons and let people make their own decisions. The jj workflow isn’t for everyone, and sometimes people’s git workflows are simple enough that there isn’t a benefit to learning a new tool. I like jj because I have to deal with complicated workflows for work and jj makes them much easier. At a different job it was much simpler and I wouldn’t have paid too much attention to jj.
I do a lot of complicated stuff with git - what sort of workflow does this solve for you?
git rebase -iandgit squashwork well for combining commits and cleaning up history. I’m not finding anything aboutjjyet that does better? And I’m finding a lot about it that are just deal breakers (auto-commit everything, make me lookup hashes of things).
