▲ 116 points
back
162 comments
I just don't have enough pain points with Git to move to something new. I don't have a problem remembering the ~5 commands I need most on any given workday. Between stashes, branches, temporary commits I later rebase, and recently worktrees, I don't lack for anything in my usage. It's universally used across both my public and corporate life, and neither does anyone need to learn a new tool to interact with my code base, nor do I need to deal with possible inconsistencies by using a different frontend on my end.
It's cool that it exists, and it's impressive that it is built on top of git itself. If you (like the author) want to use it, then more power to you. But I have yet to be convinced by any of these articles that it is worth my time to try it since nearly all of them start from a point of "if you hate Git like me, then try this thing".
If anyone has a link to an article written from the point of view of "I love or at least tolerate git and have no real issues with it, here's why I like JJ," then I'd be glad to read it.
If you've ever lived in a world of stacked commits with develop on main (i.e. not gitflow, no feature branches), combined with code review for every commit, git will soon start to aggravate you. Git doesn't make rebasing a chain or tree of commits pleasant. Git records merge resolutions and can reuse them, but it doesn't do the same thing for rebases, making them more repetitive and tedious than they should be. When you address comments on earlier commits in a chain, you need to rebase after. Git's affordances for rebasing aren't great.
And when you rebase, the commits lose their identity since commit hashes are content-addressed, despite having an identity in people's minds - a new revision of a commit under review is usually logically the same unit of change, but git doesn't have a way of expressing this.
jj, as I understand it, addresses these pains directly.
The best thing that could come out of jujitsu is git itself adopting the change-id system (which I believe I read somewhere is being considered). If you actually take time to learn your tools and how they're intended to be used, there's really not reason to learn jj IMO
Heres a great article about a powerful workflow that jj makes practical https://ofcr.se/jujutsu-merge-workflow/
Where jj shines is advanced workflows that aren’t practical with git. If you aren’t interested in those then it doesn’t give you as many benefits over git.
If you are breaking down your features into small PRs, stacking them, etc…, then jj is super helpful.
I’m also fine with git, and have used mercurial and p4 before. I think simplicity is better in this case. I do think with more and more generated code inflating the codebase with high velocity, we need to find a better way to merge conflicts.
I don't have major pain points with git either (mainly just that rebase merge conflicts can get awful to deal with), but I just love jj and I'm not looking back.
It turns out there were a lot of things that I was not doing with git because with git it would have been painful.
Now my PRs are split into human-sized commits that each contain a set of changes that make sense together, and I keep moving changes around during development to keep the history tidy, until it's time to send the pull request. If a commit introduces a typo, the typo fix should go into that commit so the typo never happened in the first place and you don't get reviews like "please fix this" and then "oh wait I see you fixed it in a later commit".
And sure, with git you could checkout the faulty commit, amend it, then amend -a and hope no one was looking, and rebase your dev branch onto the amended commit and it will often even work. Or rebase -i, sure -- have fun with it if the typo was 12 commits ago.
So I just never did that because augh.
With jj it's trivial. You just switch to that commit, fix the typo, and switch back to where you were. Or fix the typo where you were and squash the fix, and only the fix, into the commit that introduced it.
No more rebase hell. No more deleting the checkout and pulling it clean because things went sideways in a way that would be hell to fix manually -- jj takes snapshots after every mutation and rolling back is easy. No more squashing on merge to sweep the messy commit history under the carpet. No more juggling index and staged files and stashed files and all that messy business. Everything is just suspiciously straightforward. To think this could have been our lives all along!
And I'm not looking back.
It's not that I dislike git. It's just that I love jj.
I don't hate git, I like it fine and, until recently, used it exclusively on all my projects (I still use it non-exclusively). Here's an article that's written from that viewpoint:
https://www.stavros.io/posts/switch-to-jujutsu-already-a-tut...
That having been said, I didn't hate Subversion either. It was fine.
I don’t hate git either but you’ll meet very few people who will claim its UX is optimal. JJ’s interaction model is much simpler than git’s, and the difficulty I found is that the better you know git, the harder it is to unlearn all its quirks.
I have been trying Jujutsu for a few weeks. It's cool and I like trying new things. I wouldn't say that it's so much better than git, though; there is nothing that I miss in the projects where I use git.
On the other hand, I have issues with Jujutsu, one of which completely prevents me from using it in some projects:
* No support for git submodules. One can dislike submodules as much as they want, if I need to contribute to a repository using them, I can't use Jujutsu.
* The signing support is very annoying with a security key. Even if I configure 'sign-on-push', it will access the security key every time it tries to check the signature, which is pretty much every `jj st` or `jj log` after something has changed locally. I don't need to check my own signatures, IMO they should be checked on fetch and on push.
* There is no way to configure a 'defaultKeyCommand' like in git, which I now rely on (because I have multiple security keys).
Yeah, it sounds like you have specific requirements that don't let you use jj until it gets support for those. That's fair.
I also have that problem with submodules. Of course they are crap, but the project uses them.
In the past 2 months, I saw 3 articles about JJ.
Always the same starting point: "I don't understand how git works".
If you can't understand git, one of the most used tool in the whole industry, this is a *you* problem. You MUST take the time to understand how it works properly. Every job you'll get and every projects you'll work on will use a Version Control (at least I hope).
Abstracting this knowledge by using a tool that does things quite differently won't help you at all on the long run.
I am a git expert and I very much prefer jj. It enables workflows that are impractical with git. It’s hard to even imagine these workflows if you only use git because your thinking is constrained by the limitations of your tools.
Git rebase is like programming with punch cards compared to jj’s rebase being like writing Python.
Ok, I can get behind JFK's quote "We choose to go to the Moon not because it is easy, but because it is hard" - but do we have to apply the same quote to git? The way I see it, git is a tool and not a goal in and of itself. If there is a tool that does the same thing in an easier to use way (and can work with git repos), why use git? Of course, using VCS is part of the job description of almost every developer in the world, but git !== VCS...
> You MUST take the time to understand how it works properly.
Unfortunately, I agree.
It is both ubiquitous and so unnecessarily complex. The fact that all developers are required to memorize at least a few of its inscrutable incantations reflects poorly on the industry and on the judgement of its practitioners.
"if some students fail the test, the problem is of the students, if many do, is of the teacher".
Git is a bad teacher. There are a lot of things that are profound yet easy to grasp when learned and other things are called bad products. Git is one of them.
Are you writing everything in assembly? If not, your argument has no legs.
Moreover, you can use jj almost completely seamlessly with a git repo - including PRs etc to github. I do it daily and no one is the wiser.
I really loved jujutsu for the few weeks that I used it.
However, I did find all my tools that rely on Git (eg Gitlab CLI that can open merge request from the current branch) breaking because JJ operations result in detached head in Git.
In addition, mixing Git and JJ will result in your repos becoming really slow when you do need to run some Git operation.
Hm, I can't speak to the tools, I imagine you're right. I haven't found any slowness, though. Why would jj slow git down?
One of the bigger selling points of JJ just wouldn't work so well without larger team buy in for me: the ability to push stacked PRs.
I like the idea of it, but there's so much inertia around typical git workflows that revolve around the GH pull request model (with the only difference being the use of trunk based dev or some git-flow like branching strategy) that it'd be hard to change without a lot of buy in.
I still think back to Phabricator and its approach to code review, noting that it sadly never got wider traction despite having notable benefits over a completely entrenched status quo.
> Needless to say, I just don’t get git. I never got it, even though I’ve read a bunch of stuff on how it represents things internally. I’ve been using it for years knowing what a few commands do, and [...]
> If you don't like Jujutsu, you're wrong
It would be much more convincing if they had any idea of git that they were comparing it to.
Except, the fact that I have no idea of git after 20 years of use, whereas I have a great idea of jj after two months is exactly the point.
Right in the first paragraph.
> Needless to say, I just don’t get git.
What is there not to _get_, honestly? And why is jj so easier to get?
The author seems to focus on how great it is to make changes to your commit history locally, and that you shouldn't worry because it's not pushed yet.
The thing is, I don't want automatic. Automatic sucks. The point of version control is that I am able to curate my changes. The guards and rails of git is what makes me feel safe.
I am still failing to see why JJ is superior to git, or whatever.
Hmm, what guards and rails?
There are some convention people follow when working with git to make it safe to use. But those aren't git's features -- they are ways to avoid confusion.
It's not that it is superior, it is completely inferior to git :) That is why you are failing to see :)
I feel like anyone who spends just a couple of hours learning git will have a much better mental model than the crappy "Assembly line" model from the article.
Your real mental model of git should be an acyclic directed graph where the nodes are commits and the edges are ancestry. Commits represents snapshot of the project's state. Tags and branches are just text pointers to commits in the graph.
If you use this mental model, suddenly things like git rebase or git reset become far less mysterious and arcane since they are just simple graph operations. Like `git reset --hard X` means "Make current branch's text pointer point to X"
Every time I read about someone's woes with git I have no idea how people run into certain scenarios or what people are even talking about, it reads like "if you've ever tried to unfrobnicate all non-downstream flanges without rebasing your head ref onto the flange upstream of your commit, you'll know this is really hard to do in git", I just think great I have never tried to do that in 20 years of git usage and have no idea what I'd want to, I'm just going to keep using the same ~5 commands and avoiding complexity which has served me well and allowed to avoid any crazy vcs issues that seem to plague other developers
I have been trying to use jj for a couple months now, but hitting some friction with my company’s GitHub PR workflow. Specifically, after the PR is merged, the next time I fetch I always end up with a ton of conflicts. It gets hard to clean them up, so I often end up abandoning all mutable commits to start fresh.
I feel like I’m doing something wrong, as I haven’t seen this mentioned in any tutorials, but I don’t know what! :-/
> Jujutsu, in contrast, is more like playing with Play-Doh. You take a lump, cut it into two, shape one piece into something, give it a name, change your mind, give it another name, take a bit of the second piece and stick it on the first piece, and generally go back and forth all around your play area, making changes.
I love this description and it describes how I work with git. When I’m doing things locally I’m constantly committing small wip commits. When I get something the way I like it I’ll interactive rebase/just back it all up, and then create the perfect little boxes. I guess I should try jujutsu since it sounds like it might be even more for me. Although if you can’t get to the perfect boxes at the end I don’t know if I’d like it.
I have primarily used git in the terminal for more than a decade. I also used magit when I was primarily working in emacs (magit's great!). I now primarily use lazygit. While I'm not a fan of the whole UI, this is the only git tool that makes me go super fast while creating a near-perfect commit history. I tried using jj but immediately stopped after installation as it required a learning curve that I wasn't ready to commit to yet.
I don't really understand the appeal of jj as someone who uses sublime merge [0].
It has good support for submodules, a lot of the editing commits (messages, squash, move etc...) is really easy and I can also see and edit my stashes directly. Is there any benefit to jj compared to this?
"Git is too hard" is never a good argument to promote the use of a different tool.
I use git on the terminal exclusively, never had an issue amending a commit or rebasing a branch, or even dealing with conflict resolution most of the time I just use one of the automatic strategies.
I use a gui for 90% of my workflows. Another 9 percent points are hitting back in my console history to rerun commands, never mind if git or jj or POSIX that affect my working dir or index state.
What am I supposed to do, use the UI plus jj, and prompt an LLM to use which: git, or jj, in case I am too lazy to think of the right command in the remaining one percent of cases?
But in general, I like the "less states and DVCS features than git" approach, but would not switch back to mercurial just to avoid the whole "should we rebase or create merge-commits" discussions in our teams due to having a single default that might not be optimal for everyone, but just works.
Until jj supports `git rebase -x "cargo check --deny warnings"`, it's useless to me. jj has primitive support for fixing individual files that changed, but it cannot work on any linter or formatter that depends on other files.
In the age of Claude Code and other MCPs, the last thing I want is my commit history to be mutable. I've added instructions to Claude which make a commit before each modification with a summary of the conversation that caused the change. Once I'm happy with the work, I squash the commits and push up. (Which I believe is more or less equivalent to the jj workflow.)
Anyone using `jj`, how well does it scale?
I routinely use .git folders that are 11GB (+4GB checked out files) and 10k+ branches without issue.
I appreciate Jujutsu, I mean, the Gracies basically proved its effectiveness to the world, however, combat sports don't suit every temperament. The intensity can also be a bit much for those with weaker constitutions. That said, wrestling predates humanity, so it's definitely worth checking out some variation.
The article reads like you can’t change local git history before pushing. I do that all the time.
> since its commands were an inscrutable jumble of ill-fitting incantations, and it has remained this way until today
What command is he talking about? When you get that git is a graph manager, it gets really easy to manage, very quickly..
Have not finished the article yet, but it's scary how well it's guessing my thoughts and answering my questions/worries. Really well written
I like jj and would just switch over to it but I'm too reliant upon certain workflows fugitive provides. I hope to see a good neovim plugin someday.
I don’t get it. Git is working well enough. Any failure on git workflows is usually failure in team process.
When checking out means to just "reopen" an older commit, how do you checkout single files in JJ?
I’ve never had to delete .git and start over so I’m not sure if I’m doing something right or wrong. At any rate, every “jujitsu is so much easier/so much better” post I’ve read thus far has been too lengthy, vague (the mental model you’re selling is “play-doh”? Really?), and hand wavy. As far as using the tool to make it click for myself, it hasn’t. I won’t judge that the tool is good or bad, since clearly I don’t understand it enough to make that call, but the fact that I can just go back to git and be productive as I have been with it for nearly 20 years suggests the value proposition of “switch to jujutsu already” isn’t as high as the evangelists are claiming.
Too sad it does not work on Windows 7.
it's hard to take the article seriously when the author relies on a fuckgit alias on a regular basis
one of the better jj writeups. People, just TRY it out.
what im most impressed by when I read the comments to jj-related threads is how many people are handwriting assembly code.
I come to this conclusion because there's always a large amount of people saying "if you dont understand, let alone have mastered, git, then you dont get to have an opinion"
So, clearly these people similarly dont use ease-of-use abstractions like programming languages
Weird cultish vibes I'm getting, especially the "i just dont get git" part. Shows that you did no research.