It's not a "simplified model". The jujutsu model is more capable, but also more generic and thus easier to use and re-use. It's just better.

I don’t think simplified model is even the best selling point, but it’s definitely up there. IMO one of the killer features that you absolutely cannot get in git is universal undo. For example, rebases can always be a little tedious and tricky no matter how experienced you are. Not only does jj make that whole process easier and safer to work through, but if you do still manage to get to a state where you just want to go back it’s literally just an undo away.

I’d give [1] a read if you’re interested.

1. https://zerowidth.com/2025/what-ive-learned-from-jj/#commits...

It’s not just that it’s simpler, it’s that the primitives and interaction model are also strictly more powerful. A ton of extremely useful workflows that are an utter pain in the ass with git are absolutely trivial with jj.

One example is a series of dependent PRs. This is excruciating in git if you ever need to make a fix to an earlier PR because you have to manually rebase every subsequent change. It’s trivial in jj: you either fix the revision directly or you insert a new revision inbetween. The subsequent revisions are updated automatically. You don’t even have to think.

Another is splitting work into parallel branches. So often when I’m working on one area I end up making unrelated tweaks and improvements as I go. Pulling these out into their own branches is painful in git, so people just make omnibus branches that include a handful of unrelated work alongside the main task. In jj it’s basically zero work to split out the unrelated stuff onto a new branch off main, and it doesn’t require you to task-switch to a new branch. So I end up making lots of one-line PRs that are trivial to review whenever I’m doing deeper work.

Honestly one of the biggest selling points of jujutsu for me is its `op log`. You can fuck up your repo in git and that's it -- you're screwed. Or you find some extreme magic on the internet that saves you.

With jj you just "jj op undo <operation_id_that_fucked_your_repo>" and you're fine.

Editing prior commits is also pretty easy, which in turn makes fixing merge conflicts pretty easy too.

I don't especially like git. I stuck with mercurial for a long time.

But that was ten years ago. Now git is kind of hard-wired in my brain. By and large, it works well enough.

It's not really clear to me that Jujutsu offers a significant enough of a benefit to spend the time re-wiring my brain, never mind dealing with the initial setup (e.g. the unreadable colours, setting up some scripts/aliases for things I like).

Not a whole list of operations, but this comparison of one common operation between jj and git is what made it click for me.

https://lottia.net/notes/0013-git-jujutsu-miniature.html

> I feel like what would be great is a page that really shows some common but complicated operations in git and how much easier they are in jujutsu.

What I find isn't that common git operations are easier in jujutsu. They're not; sometimes they're slightly harder, due to the impedance mismatch with the git backend.

Rather, what git makes easier are operations that are next to impossible — or at least highly inconvenient — in git, and which therefore next to no-one does. That makes it harder to explain, because you're telling them there's this great new workflow that does stuff that... they don't think they need (they have workarounds), and the notion of which triggers their ick reflex if they're good at programming.

If you want this workflow, you can treat jj's `@` (nominally equivalent to git's HEAD) as the git index, then at commit time, manually squash changes to `@-` just like you would with `git add --patch`.

No that is correct, and also a habit I am trying to break. The reasonable argument is that we should stop running code with untracked state. Either the changes are important and should be committed or not. Otherwise you are recording code versions that never truly existed during development.

Where this gets extra sticky for me is tooling which refuses to distinguish repo wide config vs a local only version. VSCode being a huge offender where there is only a ‘launch.json’ and no ‘launch.local.json’ suitable for per host customization (eg maybe I am already running something on port 8888, so I need to map it to 9000, that does not mean a quirk of my environment should be committed).

In jj you tend to use `jj split` to break changes apart. The selected bits become the first revision, the remaining bits become the second revision.

I tend to do a bunch of work then split into small, bite-sized revisions. Often I split something out to a parallel revision (e.g., a separate branch) if it’s an independent thread of work like a bugfix elsewhere or a documentation fix. This is an obvious one-liner in jj but a bunch of annoying branch-switching and stashing in git.

You can also use a `git add`-style workflow. Create a new revision with `jj new`. Do it again. Make your changes, then `jj squash -i/--interactive` to select the bits you want to include. Keep making changes and squashing into the previous commit you’re building up until you’re happy. Conceptually just think of @ (the current revision) and @- (the previous revision) as the working copy and the staged copy, respectively.

I usually work, then do `jj split` to review changes I want to make commits to. This generally makes the workflow look like `git add -p`.

A decent mental model is that the top-most commit isn't generally going to get pushed up anywhere. It's like your working copy but also you get stashing "for free" (change back to main to make a new commit? All the WIP stuff stays on that branch instead of being carried over to main!)

You can use `jj ignore` or add patterns to `.jjignore` for files you don't want tracked, or use `jj edit --no-snapshot` to prevent automatic tracking during specific edit sessions.

Try https://senekor.github.io/jj-for-everyone/introduction.html .

A snippet from the intro:

"At the time of writing, most Jujutsu tutorials are targeted at experienced Git users, teaching them how to transfer their existing Git skills over to Jujutsu. This blog post is my attempt to fill the void of beginner learning material for Jujutsu."

> Is there a good explanation of Jujutsu without referring to git?

There can and will be, but at this stage in the project's life, git familiarity can be assumed.

> Am I the only one bad with memorizing SHAs when reading?

Nope! The CLI has nice syntax highlighting to show you the shortest valid prefix, so for example, right now I have something that looks like

  lzrvnkxl

but the initial l is in purple, while the zrvnkxl is in grey. This means I can just use the l when referring to the change. That can be harder to demonstrate in a blog post, which can't know how to highlight this, and so often they have no highlighting.

> Also, does it work with other people? Would it work in repo with 5 contributors? 20? 500?

Yes. Because it's backed by a git repo, nobody else needs to know you're using jj. Everyone can use the tool they choose.

Git is nearly universal, so highlighting the areas where jj makes things that are painful in git trivial and obvious isn't exactly a bad strategy. It's also worthwhile pointing out that it is interoperable with git, so your company and team don't have to change just because you do.

> Am I the only one bad with memorizing SHAs when reading?

I haven't ever needed to memorize a SHA or change ID with jj. What are you referring to?

> Also, does it work with other people? Would it work in repo with 5 contributors? 20? 500?

I have used jj for two years on teams without anyone else needing to be aware. Other teammates that I've convinced to give it a shot have switched, and we all work together happily alongside the git users. If anything, it's easier to work with others when they switch to jj because you no longer have to worry about rewriting history of branches that have been pushed. If you have a branch that multiple people are working on, that's bad form in git but it's just another day with jujutsu.

Reason I like git is because I use like 2% of its features. I don't fall for propaganda that I need to use bisect and co. 99% of git commands I call are aliased to 3 characters, so it's dense terminology doesn't bother me.

Counter point: I adopted it internally at Google (there's a backend for Piper, Google's monorepo Perforce thingy). I don't do my day-to-day work in the monorepo but I still jump in there once or twice a week. I adopted JJ because the existing frontend (Mercurial-based) is slow while JJ is fast.

It's nice, I really like it! I'll probably switch to it as my main VCS eventually. But it doesn't feel that important to me. Even though my main work involves quite a lot of annoying rebases which is where JJ really seems to shine.

I dunno I guess it's just that a) I've really mastered git and have a deeply-rooted workflow in it and b) despite my project involving annoying rebases, version control still isn't very high on the list of problems I have.

So yeah I'm basically bullish on JJ as a technology but I think movement from Git is inevitably gonna be slow and steady.

I started doing jujitsu a few months ago. The title of the article and this top comment had me bewildered until I remembered what jujitsu was in this space LOL

Do you use an IDE with git support but not jujitsu? I do (intellij), and I'm not sure how useful it would be.

I am not a magit user but from doing a little bit of reading, all of these commands are essentially first-class citizens in jj. Spinoff seems to be `jj split` (or in most cases literally nothing because the default is to edit a new, empty revision off the trunk), absorb is probably `jj rebase` or `jj squash`, and the auto-backup is either the evolog (which tracks file changes that haven't been explicitly commmited) or the op log (which lets you reset the entire repo to what it looked like before or after any operation).

There is also lazyjj as an interactive UI.

jjui is the best VCS TUI I've ever used. It's even smoother than magit, but I think most of that is because of jj itself. Spinoff and absorb are both native jj features (jj rebase and jj absorb, respectively)

https://github.com/idursun/jjui

> Working copy as commit means you have no quality control

The working copy doesn't get automatically pushed to GitHub or anything crazy like this seems to be implying. You review/curate your commit when you give it a description.

> It says it abstracts the backend, but it's not clear how something so git-influenced will have abstractions that work with something like a centralized system like Perforce or Piper that has auto-increment numeric commits.

Its Piper backend honestly works better than the Git backend. Which isn't a knock on the Git backend, but the impedance mismatch is worse there.

> Some of the design decisions are also not great. Working copy as commit means you have no quality control. The whole point of a commit is that... you commit it. So now you need a separate repo or filter to remove the worthless changes from the ones that you actually intend to commit. Bad commits polluting git histories is already a big problem.

Sorry, but saying this implies you haven't tried it. :-)

Jujutsu commits aren't equivalent to Git commits. They're implemented with a mixture of Git commits and the Git working tree, yes (if you use the Git backend!), but when you see 'commit', you should read 'named diff'.

Jujutsu also has a notion of immutable commits, by default meaning (roughly) commits which have been pushed upstream.

You can and should rewrite the un-pushed commits to clean up history prior to pushing changes upstream. jj makes that much MUCH easier than rebases and history edits could ever be with git. Most of my nontrivial jj work involves at least three or four commits at some point, everything from experiments to documentation branches, which with git I would have needed to awkwardly fit into stash or inconvenient throwaway branches.

> I'm confused what this is?

jj is a version control system. It is backend-agnostic. The most common backend is a git one, because git is so popular. This allows you to use jj on a git repository, allowing for individuals to adopt it without forcing their teammates to.

> Is it just a git frontend for people who are confused by git?

I used git since before github existed. I considered myself a git lover before I found jj. I will not be going back to git.

The thing is, jj is both simpler and more powerful than git, at the same time. People who are confused by git may like its simplicity, but I like its power.

> It says it abstracts the backend, but it's not clear how something so git-influenced will have abstractions that work with something like a centralized system like Perforce or Piper that has auto-increment numeric commits.

You already got some replies on this one, so I'll leave that to them :)

> Some of the design decisions are also not great. Working copy as commit means you have no quality control. The whole point of a commit is that... you commit it. So now you need a separate repo or filter to remove the worthless changes from the ones that you actually intend to commit. Bad commits polluting git histories is already a big problem.

This is an understandable misunderstanding. The right way to think of it is "the index is also a commit." A common way of working with jj is to do something like this:

Imagine I am working on adding some feature x to my codebase. I'll first make a change, and give it a description:

   jj new -m "working on feature x" trunk
  Working copy  (@) now at: lqqlysul c6756b49 (empty) working on feature x
  Parent commit (@-)      : ylnywzlx 8098b38d trunk | (empty) foo

Now I will make a new empty change on top of that:

   jj new
  Working copy  (@) now at: pxrvoron c823d73a (empty) (no description set)
  Parent commit (@-)      : lqqlysul c6756b49 (empty) working on feature x

Now, @- is the change that I intend to push publicly, but @ is my index. Say I add foo.rs:

   touch foo.rs

Now, when I run `jj status`, jj takes a snapshot, and it now lives in @:

   jj st
  Working copy changes:
  A foo.rs
  Working copy  (@) : pxrvoron ba7ad8c6 (no description set)
  Parent commit (@-): lqqlysul c6756b49 (empty) working on feature x

We can see the diff here with `jj diff`:

   jj diff
  Added regular file foo.rs:
      (empty)

So, let's say I'm happy with its contents. I want to stage it into my final commit. I can do this with `jj squash`, which by default takes all the diff of @ and puts it into @-:

   jj squash
  Working copy  (@) now at: pxkqmsww 9f7e1ef2 (empty) (no description set)
  Parent commit (@-)      : lqqlysul 41dc1531 working on feature x

Now that change is in @- instead of @. we can see that by passing -r (for revision) to `jj diff`:

   jj diff -r @-
  Added regular file foo.rs:
      (empty)

I don't have to move the whole change; I can do the same thing as git add -p by using jj squash -i, and only move the portions of the diff.

What's the advantage here? Well, because the index is just a commit, I can use any tools that I use on commits on the index. There's nothing like `git reset` needing to have `--hard` vs `--soft` vs `--mixed` to deal with index behavior: everything is in a commit, so everything acts consistently.

jj makes it very trivial to carve up commits into exactly what you want. It is far easier and more powerful than using the index for the same purpose.

> The biggest problems with git IMO are it scales poorly and it encourages commit pollution. Presumably jj isn't trying to tackle those problems, which is totally fine. But I am confused about which problems it is tackling. That's why I'm wondering whether it's just a frontend that the author finds more to their liking.

IMHO, commit pollution is more due to the pull request workflow than git itself, though I do think that git doesn't do that much to help you. jj can help with this kind of thing, but also on some level, it can only do so much.