Jujutsu for everyone

I’m slightly confused. jj has named branches. They’re just called “bookmarks”.

Once you track the remote bookmark, `jj git fetch` will update your local one to match the remote.

Another major caveat is that JJ doesn't work with Git LFS yet - though some progress is being made: https://github.com/jj-vcs/jj/issues/80

I ran into one thing with jj that I would say is pretty bad. I love it other than the way it bit me in this one case.

I have a repo with some code that generates a credential and writes the credential to a location specified in .gitignore so it isn't picked up by version control.

I used `jj edit` to roll back to a change before the credential path was added to the ignore file to make an unrelated change.

The result? jj instantly started tracking the credential and I didn't notice it before pushing to GitHub.

Fortunately I did figure it out pretty quickly, but that could have gone very poorly.

See also https://github.com/jj-vcs/jj/issues/7237.

https://github.com/jj-vcs/jj/discussions/3549 exists to simplify the tug workflow somewhat.

One thing that has bitten me a few times is jj randomly losing my changes. As in, I'll be working in Cursor, not run any mutating jj command (maybe I'll run jj status or jj log, but nothing else), and later on my changes are gone from my repository (often times with a message about a stale workspace).

I'm not sure if this is somehow related to my IDE, working in a huge monorepo, or something else, but it has been quite painful.

Aside from that, though, I do really like the flexibility jj provides.

> Another pain point was that jj could not colocate with light clones, like `git clone --filter=blob:none`. Maybe that's fixed now.

It's not

> Since jj doesn't have names branches

False. You need to call `jj branch set -r@ XYX` manually which can be a PITA but you only need to do that once you push. Or there is `jj git push --named XYZ=@` which moves the branch.

Hi, author here. Since the target audience is people with little to no Git experience, a detailed comparison would not make sense. I did simply make that claim because the weirdness of Git's UI is usually justified by saying how powerful it is. So this statement is just intended to ease the readers mind that they're not missing out on power by choosing a tool that's easier to learn.

Say you start on Main, then make a new branch that you intend to be a PR someday. You make commit 1. Then another. Maybe 6 more. Now you realize that something in commit 1 should have been done differently. So, you "edit" commit 1. All the other commits automatically rebase on top and when you go back to your last commit, it's there. Same with _after_ you PR and someone notices something in commit 3. Edit it, push, and it's fixed.

You can do all that in Git, but I sure as hell never did; and my co-workers really appreciate PRs that are broken into lots of little commits that can be easily looked over, one by one.

Jujutsu has many Mercurial-style features, one of them being revsets[1] - a set-notation-style DSL for selecting changesets (eg: which ones to log, etc). I have never found anything as powerful as revsets in Git.[2]

[1] https://jj-vcs.github.io/jj/latest/revsets/

[2] https://stackoverflow.com/questions/22520751/what-is-the-git...

I agree. I'm willing to give them the benefit of the doubt to some extent because existing Git UIs are pretty poor in my opinion. But I'd like to see some more meat on the bone, in particular a demonstration of why this is easier/more powerful/more convenient to use than the alternatives.

One example: Merge conflicts can be submitted as a proper entry and dealt with later: https://jj-vcs.github.io/jj/latest/conflicts/

It's also quickly followed by:

> Jujutsu is relatively new and doesn't cover 100% of the features of Git yet.

So it's more powerful except when it's not.

Other do a lot of nitpicking in workflows (with responses that are expected, like "but who cares" or "in git I could do the same"), but not answer this:

JJ is MORE powerful than git because has a BETTER SEMANTICS & ABSTRACTION.

That its. Is like when git emerge, it was more powerful than svn because was distributed.

I wanna make the point clear: Is NOT about the "amount of features or specific workflows" that with pain can be made on git and with effort could be retrofitted on jj eventually (if today are missed, like a equivalent of GitHub!).

The power is what abstraction made jj that is different to git: We work on "commits" all the time, and not need to manually sync the state. Everything derive from this.

And because is a better abstraction, it make more sense and is easier to understand.

The UX derive from this.

im glad to see you also use and love mise.

Mise, jj (and its phenomenal jjui TUI, which I see you mentioned there), and uv for python are nothing short of revolutionary, as far as I'm concerned. Just beautiful tools.

Nice article! I do think standards for tooling have gone up a lot in the last few years. Rust is certainly a part of it.

re: `fd` I also find it a lot better to do something like `fd -e py -X ruff format` than `find -name '*.py' -exec ruff format {} +`.

Part of it is that `find` seems to come from before we standardized on `--foo --bar` having an equivalent in `-fb`, and the nagging about some flags being positional, but also just the general syntax of their `-exec`, which _requires_ the `{}` to be present, but it can only ever be in one position for the `+` variant.

My one nag about `fd` is that it has two optional positional arguments, so the way I use it I sometimes wind up with `fd -e $ext "" /path/to/search`. (`fd -e $ext --search-path /path/to/search` might be a clearer alternative I should habituate myself to.)

IME positional arguments are always less ergonomic than flags/options, _especially_ if there are more than one of them and they're not mandatory.

But they're still better than the `find` syntax.

I'd definitely include nushell in this

[flagged]

What is the replacement for `git branch --set-upstream-to`?

> When was the last time you used a different VCS than your coworkers without having them switch to it too?

Nine years ago.

try jjui out and you'll interact with jj nearly 0 times going forward. Its amazing.

>but nothing more

What does that imply?

Something about appreciating only after losing

Yes, and this is the most commonly used workflow these days with jj (the "squash workflow"). You have a top commit, which is also your working directory, and you make changes freely. To "stage" something, you squash it down into the next commit (all changes, or interactively selected changes with -i aka --interactive).

This generalizes to using a whole stack of "stages", by doing ´squash --into´ to select the patch to put the changes into if it's not just the next one down.

1. You wouldn’t use git rere with jj, so that’s sort of a nonsequitor.

2. You treat @ (the working copy) like the staging area, @- (the parent of the working copy) as the commit you’re working on, and then jj squash -i (“interactive”) the parts of the diff you want back into @.

> Also I agree that the staged vs unstaged distinction is stupid

...

> I do like intentionally staging "the parts of the patch I like" while I work with git add -p

is a mysterious perspective to me. I guess with enough $(git worktree && git diff && vi && git apply) it'd be possible to achieve the staging behavior without formally staging anything but yikes

I just checked and it seems that mercurial 7.1 still doesn't believe in $(hg add -p) so presumably that 'worktree' silliness is the only way to interactively add work in their world

Jujutsu isn't really a git UI, and in some ways it's rather bad at being one (no support for making tags, submodules, or a few other things)

It's a whole new VCS, that just so happens to be backwards compatible with git, and uses git as it's backend

Similar to how git brought us cheap branching over svn, JJ brings cheap rebasing. Conflicts are no longer stop the world operations, and you can rebase, rearrange, and manage commits like never before.

If you've used tools like stacked diffs before, JJ will feel right at home. Making stacked diff PRs is almost trivial in jj

If you are already a heavy Magit user, then most of the basic ideas will probably be appealing and jj will let you bring those ideas to the command line. It will let you do some acrobatics you thought weren't possible before, ones that many users have come to love -- like rebasing a 5-way octopus merge with 2 extra leaves that result in conflicts you don't have to solve yet. (This is a technique known and popularized as "Mega Merge", which I suppose I am responsible for "inventing" along with its semi-silly name.)

I think Magit is an interesting parallel to jj. You say the "magic of git", but for both of them I think most of the "magic" has less to do with Git and more to do with the "design language" exposed to users, and by that I mean the tools that allow you to manipulate, navigate, and arrange commits (and diffs!) Git is more like a physical storage layer for both Magit and jj, but beyond that a lot of the special sauce is unique to their algorithms, their UX, and their "nouns and verbs".

In my experience, Magit users are generally harder to sell because for them jj isn't so revolutionary; die-hard Git powerusers who have been exclusively slugging it out on the command line to perform 10-stack rebases for the last 5+ years tend to be very easy to sell, in comparison. But all these users tend to understand and appreciate the power of a well-designed set of tools for commit graph manipulation. Git powerusers tend to be some of our most hardcore converts and advocates, really.

Full disclosure but I'm one of the jj maintainers and my opinion is that it's pretty good. Maybe try it out for a few days (perhaps without using Magit, if you can :)

Are there "central concepts" in the Jujutsu design?

I'm having a hard time wrapping my mind around what specific details would cause me to choose Jujutsu over Git, in particular because of Git's industry standard status.

I think this is a very interesting concept, but I think it could go farther with some more targeted marketing along these lines. Of course, if Git power users are not Jujutsu's intended audience, then this comment may be irrelvant.

I think one of Git's great weaknesses is its unfriendliness to newcomers (jargon, deep features, lack of discoverability, lack of accessible GUI frontends), so there's probably a lot of potential for a VC solution that is easier for a newcomer to jump into.

I switched from Magit to jujutsu. The only difference for me is that stacking PRs has become simpler. It's also made me more conscious of making smaller changes and shrinking what I consider "worth shipping".

Overall a positive experience, but if Magit is working for you, there's no killer feature that makes it worthwhile.

I'm also using https://github.com/bolivier/jj-mode.el which lets me do enough of what I need with jj from within Emacs.

here's a few links that you might find useful. But it would be worth exploring the other recent hn discussions on the topic - i and other unabashed evangelists have shared a lot.

A great "Megamerge" workflow

https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj...

https://ofcr.se/jujutsu-merge-workflow

And an absolutely fantastic TUI that wraps jj cli. Might be the best TUI ive ever used, and consistently getting better.

https://github.com/idursun/jjui

You will be probably excited to give https://github.com/bolivier/jj-mode.el a try.

jj is similar to a magit cli, brought to the rest of the world. There's no benefit to switching from magit.

I'm having a hard time understanding your question. are you asking how people who are unfamiliar with git and jj should mentally model a stack of PRs? and that this is a problem because it's intimidating for them when an expert (in git? in the codebase?) is reviewing their code?

if yes:

while jj does make stacked PRs quite easy, I think this tutorial is mostly aimed at people who are still getting their feet wet and not making stacks of PRs. and if the expert is intimidating, tell them to be helpful or fuck off

if no:

well I don't understand your question, but probably don't `jj edit` the commit at the bottom of a stack; `jj new` and, when you're ready, either `jj squash` it down or `jj rebase -s @ -A @-` your change into the stack instead

It's still insane to me that universal `undo` is not a basic git command.

I’ll focus only on the syntax of the command. Why you might need it at all is important, of course, but it’s nuanced and specific to how some people work (I never need this command or anything like it, for example).

> jj bookmark move

Presumably, this part is reasonably clear. “I want to move a bookmark.”

> main

Which bookmark to move. I think this is probably clear from context?

> --to @-

And here’s the part that looks foreign to a non-jj user. This syntax is familiar to jj users because the same revset syntax is used across the whole CLI. `@` is the working copy commit (the commit you have “checked out” that you are currently editing), and `@-` specifies its parent.

Because it’s just a revset, you could specify that same command in a number of ways:

- If you know the parent’s commit ID or change ID, you could use that instead: `--to abc123`

- If there happens to be another bookmark already there, you can use its name: `--to other-feature`

- You probably wouldn’t type this in the terminal, but you could do exotic things like `--to 'mutable() & description("foobar2000")'` to assign the bookmark to the work-in-progress commit that has "foobar2000" in the commit message.

Revsets used pervasively are one of the things that make the DX lovely.

`git` is a content-addressable filesystem (the "plumbing") with a VCS UI on top of it (the "porcelain"). `jj` is alternative "porcelain" using the same "plumbing". Git was initially designed to be a toolkit on which to create VCSes, over time the VCS portion of Git has become more complete but is still a very leaky abstraction, resulting in users having to use the "plumbing" commands more often than never. `jj` aims to be better "porcelain" over the Git "plumbing", and the project authors hope to eventually support other "plumbing" model(s).

In every one of these threads I learn some new axis of git that JJ doesn't support, so I really do wonder if JJ should have squatted upon a different DVCS given how much it wants to do things the JJ way leading to folks with git experience being sad

or LFS, hooks, submodules, shallow clones

.gitattributes has only caused me trouble, so I wouldn't really miss it. IMO it's a footgun.

I listened to the same podcast, and agreed with the points that Casey made. However, there were some aspects of version control that were glossed over.

What was described was actually quite close to developing through a Dropbox folder + (implied) tooling. And that makes a lot of sense for Casey Muratori's current work, which I believe is a small 5-10 person team doing game (engine) development. Such teams can quite easily work all in the same source branch (and this could in fact be preferred, e.g. for large assets in gaming).

However, as organizations grow, you want different levels of staging (that could be provided by your version control). A split between local and _the common_ stream, release branches, splits between projects or features, review states, etc.

So I believe the optimum is somewhere in the middle, and jj does take a step towards it. But still some friction remains.

I didn't think that there was something wrong with my git workflow, or that git was complicated. I switched from darcs as my primary VCS to git around 2007. I was skeptical about jj at first but gave it a try. Did not look back ever since.

My impression is, that git is ok for managing shared history. And thats what i was using it for mostly. But jj added another whole dimension for managing my work in progress, different paths of code that i am working on in the moment. jj made it almost frictionless. I did not know I was missing it, but i'm not going back.

I was one of the early adopters (cause I enjoy kicking the tires on things) and brought awareness of the need for gpg signing at all into JJ, so I wouldn't overlook the value in bumping https://github.com/jj-vcs/jj/issues/6688 so they can eventually get you there

GitHub needs to redesign PRs to properly support stacking them. It isn’t a client problem, but jj does make rebasing multiple branches correctly trivial, so if GitHub supported this workflow in a non-pretend fashion, it’d work.

If rebasing correctly is enough to support your use case, then the answer is ‘it’ll work’.

Kind of. You can do most of it by hand, and there are some community made tools that improve the experience and basically give you graphite lite

https://github.com/keanemind/jj-stack

jj is great, but it doesn't quite fill the void of Graphite.

I've heard good things about https://abhinav.github.io/git-spice/

No, sadly, that's more of a Github limitation.

Generally. JJ will sometimes leave git in a detached head state, but it's usually pretty easy to recover from on the git side. The one thing I'd caution on is making sure you keep your bookmarks on the JJ side up to date. These translate to branches, which git needs to know where it is

You might want to set up this feature: https://github.com/jj-vcs/jj/discussions/3549

Working copy handling differences is certainly an aspect of jj, but, at least for me personally (esp. given me having grown up with git), it's probably my least favorite difference from git. And yet I've moved most of my personal things from git to jj (albeit with a bunch of custom scripts to make the working copy stuff more git-y).

A significant other thing jj does is introduce change IDs (i.e. a (randomly-generated) ID that stays stable even as a commit is amended), with which it should be easier to track changed commits across forks/rebases/edits/pulls/fetches, though I've yet to use jj for collaborative projects to see how much that pans out.

Generally jj makes rebasing things, and generally editing history so much more easy than git, so force-pushes messing with branches is much nicer to "fix" however needed. Being able to leave commits in a conflicted state and resolving only when actually needed also should help.

I am think you are misunderstanding the entire premise of git. There is no "force push to trunk breaks every other developers' working copy." There is no central repo/trunk where all the commits are pushed. You are probably thinking of svn.

In git, your repo is the canonical repo and that is where you work. You work on a new feature and when you are ready, you "git format-patch" and "git send-email" to the community via the mailing list or other developers. A discussion may happen and people may or may not decide to apply the patch to their own repositories, with "git am." This doesn't break every other developers' working copy because they decide how to apply the patches they got in their email. No central repo, no trunk, guaranteed by the d in git dvcs.

> A rebase may unintentionally overwrite someone's work

Since you're rebasing, you're intending stuff; nothing is lost until you force-push.

> A force-push to trunk breaks every other developer's working copy.

Which is why you avoid it and set the remote main branch to protected. You can't force push by accident, you intend to forcibly overwrite the remote branch.

JJ let's you have multiple "versions" of the same branch, although not directly. Typically it comes about when you've made changes and someone else has made changes, and the conflict resolution can't happen cleanly, due to each path taking a difference, unreconcilible approach. You'll have to resolve those and unify the different "branches", but it's no harder than any rebase in git land (generally easier because jj's conflict markers are even better than git's 3 part system)

The ability to resolve merge conflicts one part at a time is a game changer itself.

> A force-push to trunk breaks every other developer's working copy.

Only if they pull your broken trunk as well. Otherwise you're just wrong.

> A rebase may unintentionally overwrite someone's work.

No only your copy of someone's work.

> - i'm forced to be "strict" with my changeset since there's no `git add -P`

JJ split is your friend

> - bookmarks are a pain to keep up-to-date with `jj new`, i don't know if i even want to do that. for multi-commit changes, i've defaulted to `jj new` a couple times as needed, and `git push -c` the latest.

Check out the common community alias JJ tug. It's used enough they're considering adding it as a feature

Just a few tips:

> - i'm forced to be "strict" with my changeset since there's no `git add -P`

Check out the command `jj split` and possibly `jj squash --interactive`.

> - bookmarks are a pain to keep up-to-date with `jj new`

There's a neat alias a lot of people use:

```toml [aliases] tug = ["bookmark", "move", "--from", "heads(::@- & bookmarks())", "--to", "@-"] ```

It finds the closest bookmark and moves it to `@-`. Pretty much exactly what you want when adding more commits on top of an existing branch.

Can't you just add an alias that takes two arguments that takes a message and a bookmark name? I aliased the entire describe, commit, bookmark and push to a single command.

IMO its inspired by the best parts of git, hg, and darcs. jj split alone is worth the price of admission IMO

I haven't done a TON of scripted use of jj, but when I have the built in templating has come in clutch. If you want a command to return in a certain format (or include/exclude certain metadata) it's usually easier- and probably more future proof- to tweak the jj command's template than to parse the string in your script.

Not really, but it's a strong enough description that people who know what both are would understand

JJ is a whole new VCS, that just so happens to be backwards compatible with git, and currently uses git as it's storage engine

It builds atop the knowledge we gained since mercurial and git were both new, not making mistakes that the others made, as well as knowledge from newer VCS systems like fig and sapling

> Would it be accurate to describe Jujutsu as "a Mercurial-inspired frontend for Git"?

In my opinion: yes. (Maybe with a slight caveat that I think some of the Mercurial inspiration came through Sapling.) And it's not limited to Mercurial/Sapling ideas, it has some new stuff too, but I think that still counts as "Mercurial-inspired".

> Also, another question I have for people who have used Jujutsu: Is it focused on interactive use, or is it also convenient to use for automatic/non-interactive use?

I use it in automation. I'm hampered because the primary VCS for the automation is git, so I'm doing more of a compatible layer and can't go too crazy with the jj-specific stuff.

But jj has some features that are excellent for automation.

Example: you can manually wrap things in a discardable transaction: grab the current operation ID, do all kinds of weird mutating operations that add and remove patches, maybe even merge and rebase, and then at the end (maybe in a `finally` block) do `jj operation restore <id>` and everything will go back to the way it was.

Another example is that if you want to tweak something, say a config file, in N different ways, you don't have to mess around with naming branches and switching between them or whatever. Just create N independent child commits and make the appropriate changes in each.

Or conversely: make M children for the M values of configuration value 1 and N children for the N values of configuration value 2, then create a new multiparented child (a merge commit) for each combination. `jj new <a> <b>` creates a merge commit with parents <a> and <b>, so:

    jj new $base -m 'var1=a'
    jj new $base -m 'var1=b'
    jj new $base -m 'var2=x'
    jj new $base -m 'var2=y'
    jj new 'description("var1=a")' 'description("var2=x")' -m 'var1=a, var2=x'
    # run scenario 1 with those settings
    jj new 'description("var1=a")' 'description("var2=y")' -m 'var1=a, var2=y'
    # run scenario 2 with those settings

If I understand you correctly, then you can use `jj interdiff --from name-of-branch@remote --to name-of-branch@git` in order to recover the diff between the remote branch commit and your local version of it; you could then turn that invocation into a Git .patch file and reapply it with patch(1). This only works for one commit.

The more general solution you're looking for I guess is some kind of "split based on interdiff" or something like that. I don't believe there's any way to accomplish this in a single stroke, though.

I fixed this by changing the default immutable heads to include all remote bookmarks. This way, you cannot edit them and the new commit is automatically created when you push to the remote branch.

  [revset-aliases]
  "immutable_heads()" = "trunk() | tags() | remote_bookmarks()"

I also run into this often, I wonder if there is a simple built-in feature that would allow you to diff against the remote.

There's a few different ways to fix this, but here's what the official docs suggest: https://jj-vcs.github.io/jj/latest/FAQ/#i-accidentally-chang...

TL;DR - `jj evolog` and then restore changes from the relevant secret commit ID

Is `jj split` a good option?

I used to work on Sapling and Mercurial while at Facebook. I've been using Jujutsu full time for the last two years.

Jujutsu is in a sense the final form of that style of VCS, which I characterize as making commits first-class rather than branches, and providing powerful tools for managing long queues of stacked changes (git rebase -i is nice but has many limitations that don't exist in Jujutsu).

I go into some more detail in my testimonial, the first one at https://jj-vcs.github.io/jj/latest/testimonials/#what-the-us....

I’d second Rain’s reply, but having gone from git to sapling to jujutsu, I feel like the jump from sapling to jujutsu was as big as the jump from git to sapling, in terms of “oh, this is a way nicer workflow”. I really like and miss Sapling’s interactive smart log, but I found jj’s conceptual simplicity to be more compelling than ISL. That said, VisualJJ and Jujutsu Kaizen (both listed on https://jj-vcs.github.io/jj/latest/community_tools/) might give you the ISL-style experience you’re looking for.

I'm mostly git -> mercurial -> sapling -> jj. For me, Mercurial -> Sapling was a mostly lateral, slightly upward move. Sapling -> jj felt really good, though oddly not because anything felt horribly wrong or missing in Sapling. Things just feel nicer and lighter in jj. Once I know a couple of things, I can combine them to do lots and lots of other things without learning any new commands. In fact, the total command set is pretty small, yet covers about the same range as other systems (a little more here, a little less there). Also, improvements come in at understandable and predictable places: at its current stage of development, it's not growing brand new commands. It is instead slightly improving existing commands to enable significant new capabilities. It has the feel of a well-designed system with mostly orthogonal components. (Give it a decade, and perhaps it'll start crumbling under its own weight too...)

This over-estimates the lock-in, because jj uses git under the hood. You can try jj, and your colleagues need never know. If you hate it after a couple weeks, you can return to git, no sweat.

It's much easier to try out than earlier VC systems.

Here:

  $ jj new -m 'build my feature'
  $ touch my_feature.c
  $ jj new -m 'add some other feature'
  $ touch other_feature.c
  $ jj bookmark move main -t @
  $ jj git push

Replaces it entirely

Check out jjui. While it's not a 1:1 of lazygit, it's better in some ways and lacking in others, but quickly getting better. I really enjoy that it shows you the command every action runs under the hood. Great to expand your knowledge of JJ early on

There is a lazyjj but I don’t use lazygit so I can’t comment on how complete of an alternative it is.

You might be interested in pijul then, which has a theory of patches that is interesting.

jj’s design is not constrained by git. git is one possible backend, but you don’t even need to use jj with git. I will eat a shoe if you can name something jj is prevented from doing by its relation to git.

what does "retrofitting" git implies? I am confused by the agent-specific systems bit.

Why would agents need a specific versioning system?

Yes. I have one repository, which is a fork of an OSS project, with a 7-way octopus merge of various patches I carry, and another 2-way merge on top of that one. Every week or two I pull the latest changes from upstream and I rebase all 9+ branches in a single command. If there are conflicts on any one of the parallel streams of work, I can trivially fix each conflict individually in any order I want.

Jujutsu does not treat merge commits any more or less special than non-merge "1-parent" commits. (We used to do this, actually, and occasionally special case merges, but most users found it very confusing.) This regularity means most commands work fine on merges. 'jj new X' is a new commit on top of X. 'jj new X Y' is a merge commit with X and Y as parents. 'jj new X Y Z...' is a 3-way merge, and so on and so forth for any number of commits. Similarly, 'jj rebase' can handle moving commits and preserving the graph structure no matter how many edges are involved in particular, and can add or remove parents from a given commit. This means that conceptually the jj commit graph is merely a simple, ordinary DAG, and operations are transformations on the DAG like you expect.

Actually, this exact workflow is beloved by many community members, and I guess I can take responsibility for popularizing it originally, the "Mega Merge" technique. Instant, easy rebase is an essential part of making this technique viable.

- https://ofcr.se/jujutsu-merge-workflow - https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj...

What does git rebase --rebase-merges do in this case? How does it botch up the repo?

To reinforce the sibling reply with a concrete example:

Let's say you've got a few feature branches, all based of the trunk branch.

  $ jj
  @  ozywpwxm samfredrickson@gmail.com 2025-08-31 13:21:59 b2f1364d
  │  (empty) (no description set)
  │ ○  qxoklwxv samfredrickson@gmail.com 2025-08-31 13:21:27 9cda0936
  ├─╯  (empty) Feature C
  │ ○  ukqynvts samfredrickson@gmail.com 2025-08-31 13:21:26 ceee7029
  ├─╯  (empty) Feature B
  │ ○  nwtxnvxp samfredrickson@gmail.com 2025-08-31 13:21:24 9ccbedf6
  ├─╯  (empty) Feature A
  ◆  yxuvtolz samfredrickson@gmail.com 2025-08-27 09:49:16 master git_head() 8e80b150
  │  Update Claude Code to 1.0.93.

  $ jj new q u n
  Working copy  (@) now at: zzxxqlzr fb73d4dc (empty) (no description set)
  Parent commit (@-)      : qxoklwxv 9cda0936 (empty) Feature C
  Parent commit (@-)      : ukqynvts ceee7029 (empty) Feature B
  Parent commit (@-)      : nwtxnvxp 9ccbedf6 (empty) Feature A
  $ jj
  @      rzouzmyw samfredrickson@gmail.com 2025-08-31 13:25:56 fb73d4dc
  ├─┬─╮  (empty) (no description set)
  │ │ ○  nwtxnvxp samfredrickson@gmail.com 2025-08-31 13:21:24 9ccbedf6
  │ │ │  (empty) Feature A
  │ ○ │  ukqynvts samfredrickson@gmail.com 2025-08-31 13:21:26 ceee7029
  │ ├─╯  (empty) Feature B
  ○ │  qxoklwxv samfredrickson@gmail.com 2025-08-31 13:21:27 git_head() 9cda0936
  ├─╯  (empty) Feature C
  ◆  yxuvtolz samfredrickson@gmail.com 2025-08-27 09:49:16 master 8e80b150
  │  Update Claude Code to 1.0.93.
  ~

  $ vim README.md
  $ jj squash --into n
  Working copy  (@) now at: rzouzmyw 30ff9b0f (empty) (no description set)
  Parent commit (@-)      : qxoklwxv 9cda0936 (empty) Feature C
  Parent commit (@-)      : ukqynvts ceee7029 (empty) Feature B
  Parent commit (@-)      : nwtxnvxp fb3cca28 Feature A
  $ jj
  @      rzouzmyw samfredrickson@gmail.com 2025-08-31 13:27:41 30ff9b0f
  ├─┬─╮  (empty) (no description set)
  │ │ ○  nwtxnvxp samfredrickson@gmail.com 2025-08-31 13:27:41 fb3cca28
  │ │ │  Feature A
  │ ○ │  ukqynvts samfredrickson@gmail.com 2025-08-31 13:21:26 ceee7029
  │ ├─╯  (empty) Feature B
  ○ │  qxoklwxv samfredrickson@gmail.com 2025-08-31 13:21:27 git_head() 9cda0936
  ├─╯  (empty) Feature C
  ◆  yxuvtolz samfredrickson@gmail.com 2025-08-27 09:49:16 master 8e80b150
  │  Update Claude Code to 1.0.93.

  $ jj git fetch
  remote: Enumerating objects: 17, done.
  remote: Total 12 (delta 6), reused 0 (delta 0), pack-reused 0
  bookmark: master@origin [updated] tracked
  $ jj
  @      rzouzmyw samfredrickson@gmail.com 2025-08-31 13:27:41 30ff9b0f
  ├─┬─╮  (empty) (no description set)
  │ │ ○  nwtxnvxp samfredrickson@gmail.com 2025-08-31 13:27:41 fb3cca28
  │ │ │  Feature A
  │ ○ │  ukqynvts samfredrickson@gmail.com 2025-08-31 13:21:26 ceee7029
  │ ├─╯  (empty) Feature B
  ○ │  qxoklwxv samfredrickson@gmail.com 2025-08-31 13:21:27 git_head() 9cda0936
  ├─╯  (empty) Feature C
  │ ◆  zvpmmzru samfredrickson@gmail.com 2025-08-29 15:59:55 master 658a3d12
  │ │  Update Claude Code to 1.0.98.
  │ ~  (elided revisions)
  ├─╯
  ◆  yxuvtolz samfredrickson@gmail.com 2025-08-27 09:49:16 8e80b150
  │  Update Claude Code to 1.0.93.
  ~

  $ jj rebase -s 'roots(trunk()..mutable())' -d 'trunk()'
  Rebased 4 commits to destination
  Working copy  (@) now at: rzouzmyw 88ed8085 (empty) (no description set)
  Parent commit (@-)      : qxoklwxv 005442c3 (empty) Feature C
  Parent commit (@-)      : ukqynvts 23923cf2 (empty) Feature B
  Parent commit (@-)      : nwtxnvxp 769d0539 Feature A
  Added 0 files, modified 2 files, removed 0 files
  $ jj
  @      rzouzmyw samfredrickson@gmail.com 2025-08-31 13:32:08 88ed8085
  ├─┬─╮  (empty) (no description set)
  │ │ ○  nwtxnvxp samfredrickson@gmail.com 2025-08-31 13:32:08 769d0539
  │ │ │  Feature A
  │ ○ │  ukqynvts samfredrickson@gmail.com 2025-08-31 13:32:08 23923cf2
  │ ├─╯  (empty) Feature B
  ○ │  qxoklwxv samfredrickson@gmail.com 2025-08-31 13:32:08 git_head() 005442c3
  ├─╯  (empty) Feature C
  ◆  zvpmmzru samfredrickson@gmail.com 2025-08-29 15:59:55 master 658a3d12
  │  Update Claude Code to 1.0.98.
  ~

Thanks for the explanation!

For the defense of git add and the index, I actually personally enjoy it. I discovered git add -p recently, and it's quite nice.

It's like a way to say: let's prepare a commit with only this part of the file, but not yet this one as it's not yet finished.

For example, you can git add -p only the dependencies of a package.json, push that so others have it, and continue working on the scripts part.

I use often as well the index in order to have more granular commits that follows well Conventional Commits, when I want to have a `docs:...` for the readme update and a `feat: ...` for the src change

jj looks interesting, I will take a look!

> fame

I think it's great when people become famous for building useful, high-quality works, and other pro-social activities!

> money

Jujutsu is free software in both senses of the word.

same, I'm kinda disappointed

There are many different guis you can use with jj.

It’s true that submodules aren’t directly supported, but you can use the git commands to manage them hntil native support comes.

You can have most of that stuff, but it doesn't sound like that would sway you anyway. (And those 4 missing features may truly be showstoppers for you, in which case you're absolutely correct to stick with git.) There are early adopters and late adopters, and both have good reasons for being the one they are. You do you.

This feels like a troll, but I'll answer anyway.

The first command you mention is `jj bookmark move main --to @-`, which apart from the `@-` part, is easily read and does exactly what is written. It moves the main bookmark to the parent commit. The main difference to git here is that updating a branch is an explicit action. Jujutsu supports creating aliases and many users have a `jj tug` alias that moves the current closest branch to point to the parent commit. `git add .` just adds all changed files in the current directory to the current commit. That's an entirely different thing and Jujutsu takes care of doing that automatically.

The second command creates a git repository and while it is longer, I doubt the extra keystrokes will hurt you much. If it's too long, just alias it.

As for using `jj git`, since Jujutsu supports multiple backends, backend-specific commands require the `git` namespace. You generally only need it for cloning, pushing and fetching (with the option for aliases again). You'll rarely need to create a new repository or add a remote.

> Complicated workflows requiring deep understanding might be harder to learn because of a higher abstraction.

That's a fair complaint, and where other git porcelains have failed in the past.

I think the trick is that jj isn't raising the level of abstraction. Well, maybe in one place: there are change IDs in addition to commit IDs, and most of the time you'll want to be working with the change IDs. But even then, you could just use commit IDs, you'd just need to be looking them up all the time.

jj adds on a minimum of new functionality. It just turns out that if you make the already-existing git graph the object of your CLI commands, you can actually expose all of the operations you need with a much smaller set of primitives, even those for constructing your complicated workflows. git has accreted commands and flags to handle everything you need because it restricts its focus to a single commit or ref. Sometimes a command will use that commit to imply a whole branch, sometimes not. It avoids mutating things because that'd make you lose track of the holy commit, but then it has to provide lots of tools for when you want to mutate things. It has a staging area so that you can delay creating a commit until it's stable enough -- but now you have another concept. Stashes are similar.

(This actually undersells jj a bit. The op log and deferrable conflicts, for example, are bizarrely useful in practice even though they aren't fundamentally "needed". Nor do they raise the abstraction level. But going into that would dilute the message.)

> deep understanding

It took me less than one day to switch from git.