33
Madeleine Mortensen: Jujutsu For Busy Devs (Part 1)
(maddie.wtf)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 02 Aug 2025
33 points (88.4% liked)
Programming
21948 readers
835 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
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:
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.