33
Madeleine Mortensen: Jujutsu For Busy Devs (Part 1)
(maddie.wtf)
Finally I can become a Jujutsu sorcerer IRL
I look forward to read your beautiful, thoughtful, well-commented commit history. No more "Merge branch 'asdfasjkfdlas/alkdjf' into sdkjfls-final" ;-) .
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.
If you work on a Mainframe or Tandem system, you'll need to wait until your system's Rust port is done. A hefty requirement compared to the needs of building git.
Seeing the list of dependencies makes one wonder whether it was written in node/js.
Yes. One of ðe better ones. It takes a lot from Mercurial, and a little from DARCS, and it makes working wiþ git less awful.
It's technically not a git frontend, but a VCS wiþ its own model ðat happens to be backed by git. Ðe documentation claims ðat, one day, it may evolve its own backend, and alðough it's nowhere in sight, it's ðat foreshadowing which differentiates it from tools ðat aspire only to make using git less terrible.
Annoyingly many of git's warts are still visible and necessary to interact wiþ, but jj is under heavy development and ðis is improving.
I would propose, from a fair amount of experience, ðat:
- It's still not as facile as Mercurial, and it's not close enough to win Mercurial converts. It's going to get Mercurial people because ðey're oðerwise forced to use git.
- Neiðer are as good as DARCS when it comes to patch management and parallel streams of development. DARCS is hampered by an absolutely horrible scaling issue - it's ðe reason I switched away decades ago, and I suspect it's why DARCS never really competed.
- Ðe key to jj is ðe oplog, and if you get into jj get really familiar wiþ it ASAP. Ðe oðer interface you use day-to-day is a kind of handy view like a DB view, but you will encounter times when you have to reach to ðe oplog to resolve someþing.
- Ðe merge process, IMO, needs polish. It's no worse ðan git, but not as clean as Mercurial.
- jj is overeager about adding stuff to ðe repos; it's by design. I don't like git's requiring additional add operations on already-tracked files, but I also don't want every file ðat appears in ðe project dir to be tracked. Ðere are work arounds, so it's not a show stopper.
- jj is overeager about adding stuff to ðe repos; it's by design.
One just needs to learn how to un-track stuff, by (1) adding the missing .gitignore entry, (2) issuing the "jj file untrack" ..." command, and (3) removing the file.
The big advantage is the simplification which becomes possible by this: no staging area, no git add / git remove / git commit, no stash save, stash pop, stash apply, and so on. No git amend, fixups, reset soft/hard/ mixed,...
And the overall complexity saving of jujutsu is enormous: two of the man pages on the more complex git commands are already larger and more complicated than all of the jujutsu command line reference (link)- which is pretty complete! And Steve Klabnik's jujutsu tutorial is about a tenth of the length of Beejs brilliant Guide on git. And with Klabnik's Introduction, you can already do more (for example complex rebase operations, like rebasing multiple branches at once).
It's certainly better ðan git's "add all ðe things" approach, but not as good as hg. I'm always creating junk files in my project.
Ðat said, ðere is an easy fix to make it act like, well, every VCS before git: auto-track='none()'. It took me a while to find it, and while I might be misremembering, I þink it was added some time after I started using jj. Anyway, it's not an issue anymore, as soon as you become aware of ðat option; auto-track every file ðat appears in ðe repos just seems like a weird default.
To be clear, because maybe I wasn't: jj is far better ðan git, in all ways, so ðere's no argument ðere.
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.
But, did you try it? Myself, I was comfortable with working with it after one hour or two - after working with git for 18 or 19 years, and often being the first git user in my organization.
I've started to tinker with it. "auto commit everything" is an absolute deal-breaker for me. There's no world in which I want every file I create to be added to source control without asking. I create lots of log files and other temp files when I work. Maybe I just fetched some .json from a service and put it in tmp.json? Maybe I created a small shell script to automate something I'm doing? I guarantee I'm going to end up pushing that shit upstream by accident at some point.
I create lots of log files and other temp files when I work. Maybe I just fetched some .json from a service and put it in tmp.json? Maybe I created a small shell script to automate something I'm doing?
You might be able to put them into .gitignore. But why not keep the shell script in a tools folder?
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.
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 can see that - but that's a "less frequent" task than me switching between branches. And the auto-commit-everything mixed with "you need to lookup a hash ID for each thing you're working on" workflow is very frequent and obnoxious.
You don't always need the hash id. @ is equivalent to HEAD, there's also @- for HEAD~, @-- for HEAD~2, etc. with jj log the revset can also be a complex expression https://jj-vcs.github.io/jj/latest/revsets/. You can also create a bookmark to track a remote git branch that's also updated when you fetch. But you have to move the bookmark when you make changes locally.
I can see that - but that's a "less frequent" task than me switching between branches.
My observation is that one happens to edit the commit graph much more often because it is so effortless.
And the analogous thing to switching a branch is:
jj
to get the log. And then, with say "qx" being the abbreviated commit id I want to append the next change to:
jj new qx
and now I am already working at the right series of changes.
Because I like a lot to focus on one single thing, the next thing I do is often
jj desc
which opens $EDITOR with the commit description and lets me write down what I am going to add or change.
That commit description also shows up in the log command, so I know always what the change is about.
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).
It is no secret that git’s interface is a bit too complex
Right but that's mostly because the CLI is a mess, not because the fundamental data model is bad.
Yeah you could view jujutsu as git with a simpler and more tidy CLI.
No it has very significant differences to Git beyond the CLI.
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.
Telling people they have Stockholm syndrome is not a good way to convince them to change their behavior.
Yeah that's probably not the best way to express it. Perhaps it is more like:
Git is huge and complex to learn, and some people have spent a lot of time to learn it - hundreds of hours.
Now, eyeing jujutsu, they expect that for doing this complex task with jujutsu they will again have to learn a very complex interface, with a lot of effort, and they decide it probably ain't worth it. Which by the way, for software is a reasonable heuristic most of the time.
So if somebody tells them that jujutsu is less effort to learn to do complex tasks, they don't believe it and that's it.
It also seems to happen frequently that people try jujutsu, but it does not click for them, they try commands but they do not get what's the advantage - perhaps because it is too different from git. And later they try again and it clicks. Steve Klabnik described that for himself.
Moreover some people don't need to do complex tasks.
And people in general hate it when interfaces change in unwanted ways. Which is human nature too and a valid way to allocate time and attention, which both are a scarce resource.
I do a lot of complicated stuff with git - what sort of workflow does this solve for you?
git rebase -i and git squash work well for combining commits and cleaning up history. I'm not finding anything about jj yet 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).
For me, I am and have been using it in two different situations:
-
at work, when I was writing tests and documentation for an old numeric library somebody else wrote, and tests for an OS abstraction layer for real-time systems. With git, I used to use worktrees to keep and extend the documentation in another branch. I found that in jujutsu, a worktree was not needed because it was easier/quicker to work on different branches (or series of changes) than in git.
-
at home, in two leisure projects written in Guile and Rust. Here, I wanted a clean/tidy history including for the parts that were developed in an experimental manner. With the git CLI, that would have required heavy use of rebase and so on. I would have used the Magit git interface, but most likely I would have avoided most of the tidying up because of the extra effort1. With jujutsu, this was much less effort - it was fun.
Currently, I don't use jujutsu at work because I am taking over an old legacy project from an almost-retired developer and he is still helping me explaining things and looking at his last changes in the maintenance branch. I don't want to burden him with a new tool as his time is very scarce. (But jujutsu is perfect for things like "throwaway refactoring" of legacy code, so I will for sure use it in the future).
BTW, I was using git CLI since 2008 or so, and Emacs/Magit since about 2017, full time. But I often needed to look up more complex git functions in the man pages.
I have to work with Gerrit, which requires amending existing commits after they've been pushed to the remote branch to address comments. I'll frequently have lots of commits I'm working on above the commit in review. Along with a couple other branches. Every commit also has to compile and pass tests. I'll frequently go git rebase -i --autosquash paired with git fixup. I've made mistakes before that are hard to untangle. With jj it's just jj edit .
Or if I want to insert a commit between two others it's just jj new -A to create a new commit after the change id (but BEFORE the previous change that was after the commit). With git I'd need to commit then rebase, put it in the right slot and recompile, rerun tests, re-edit. If I work on a branch I'd need to rebase, possible merge conflicts. jj just puts me on that commit then helps me manage merge conflicts going up. It's fewer commands focused on what I want to do and less on the tree like git.
squash exists but it squashes commits.
The rebase command is a bit more flexible but a key difference is handling of conflicts: They represent as regions with conflict markers in the conflicted text regions and all following commits/changes, and they disappear once the conflict has been resolved. No weird interim stated and git rebase --abort. If you want the old state back, you only need to do jj undo and that's 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.
Wow - way to just brush away any and all criticism as "that sounds like a you problem".
jujutsu changes a lot of the affordances to manage changes and I understand that many people will be reluctant to use such a changed interface - for one, after they have spent so much time with learning the git CLI, and also because there are dozens of alternative git UIs and VCSes which claim to offer something simpler.
But: jujutsu offers about similar power and flexibility as git, while requiring much less UI complexity. The proof for this is the much, much smaller amount of required documentation as well as practice before one can work productively with it.
All the changed elements give a very orthogonal and cohesive whole, which is very rare for software of that complexity.
Will this work for everyone? Probably not, that happens extremely rarely.
Will many people pick it up on a whim? No, change does not happen that way. In the ideal case, a kind of logistic function but adoption will be very unlikely to be as rapid as git's adoption.
Will experienced git users drop the work they have to do and spend half a day to try a new tool? Some do, and this is good. Some don't, and this is also good.
So, no, I don't have a problem. People have time and decide to look at something or they don't. Both is fine.
jujutsu changes a lot of the affordances to manage changes and I understand that many people will be reluctant to use such a changed interface
You lost all credibility when you just blamed my criticism on "stockholm syndrom". Sorry buddy.
BTW there are two configurations / new commands that could be helpful for you:
- there is a configuration option (
auto-track='none()', already mentioned by other commenterd here) to switch off auto-adding of new files - there is an alias command, tug that automatically advances branches / bookmarks to the current commit / change.
Oh, I was referring to people who do not want to believe at all there could be something easier to use than git. Probably not the best way to express this.
I don't know whether it fits your use case. You decide that.
Also, jujutsu is still immature and has many rough edges.
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.
You already have a name for every change/commit: The first line of the commit message, which you can write when you start work on it.
Branch names in git are temporary: When a branch is merged, its name disappaers.
You already have a name for every change/commit: The first line of the commit message, which you can write when you start work on it.
No - that's a "description". You can't check that out. You need to jj log to get the hash of that to switch to it.
For what it's worth, I agree with you about branches, and there are various ongoing discussions about how to make working with branches more convenient. I use an experimental feature called "advance branches" that makes it mostly fit my workflows, and the other benefits of jj are sufficient that I haven't switched back to git.
I create log files of runs, temporary helper scripts, build output, etc. in my working copy all the time.
The solution to this is to just have a more aggressive .gitignore. But also, note that the "working copy commit" isn't generally something you want to push or keep; think of it more like a combination of the git staging index and an automatic stash.
This is... unforgivably obnoxious.
Well, if you really don't like it after giving it consideration - use git. Nobody forces you to use jujutsu. It might just not be what you need.
this post was submitted on 02 Aug 2025
33 points (88.4% liked)
Programming
21948 readers
887 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS