“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.
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).
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.
You lost all credibility when you just blamed my criticism on “stockholm syndrom”. Sorry buddy.
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.
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).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 <change-id>.
Or if I want to insert a commit between two others it’s just jj new -A <change-id> 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.