this post was submitted on 02 Aug 2025
30 points (87.5% liked)
Programming
21924 readers
786 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
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.
"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.
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.
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 -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).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.
squashexists 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 dojj undoand that's it.