So this is a git frontend I guess?
this post was submitted on 02 Aug 2025
21 points (83.9% liked)
Programming
21903 readers
423 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
Yeah. 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.
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 adding the missing .gitignore entry, issuing the "jj file untrack" ..." command, and removing the file.
The big advantage is the simplification which becomes possible by this: no staging area, no git add, 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).
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" ;-) .
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 19 years, and often being the first git user in my organization.
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).
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.
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 don't like it - use git. Nobody forces you to use jujutsu.