Immutable nodes prevent you from modifying already-published commits. For simplicity, we'll disable this protection, adding a local bookmark (i.e., Jujutsu's branches) for each remote branch:

$ jj bookmark track '*' --remote origin

Good, you are ready to go:

$ jj log

@  p            empty
○  zx           Click alternates Xs and Os main
○  v            Click sets a X
○  s            Square has state
│ ○  o          Play instructions
│ ○  kx         Play manual
├─╯
○  n            Square is interactive
○    ru         Board() invokes Square()
├─╮
○ │  ym         fix name: Square -> Board
○ │  x          WIP delete me
○ │  yz         LICENSE
○ │  ws         A board full of X
├─╯
○  kk           Displays X X
○  wx           Fails
○  rx           Scaffold applicatio
◆  zz      🔒   empty

Merge

A couple pages ago I teased you with a puzzle: you've mastered creating branches of empty commits; but how do you merge them?

Say you want to merge zx with o, and go from:

○  zx           Click alternates Xs and Os main
○  v            Click sets a X
○  s            Square has state
│
│ ○  o          Play instructions
│ ○  kx         Play manual
├─╯
○  n            Square is interactive
│
~

to:

@    vz          Here's the merge
├─╮
│ ○  o          Play instructions
│ ○  kx         Play manual
○ │  zx         Click alternates Xs and Os main
○ │  vv         Click sets a X
○ │  s          Square has state
├─╯
○  n            Square is interactive
│
~

jj new -r X

jj new -r o -r zx -m "Here's the merge"

If you got it, kudos. That wasn't an easy one!

Unmerge

How to unmerge?

@    vz         empty Here's the merge
├─╮
│ ○  o          Play instructions
│ ○  kx         Play manual
○ │  zx         Click alternates Xs and Os main
○ │  vv         Click sets a X
○ │  s          Square has state
├─╯
○  n            Square is interactive
~

That's an easy one! If merging was the last operation, just jj undo:

$ jj undo

@  p            empty
○  zx           Click alternates Xs and Os main
○  v            Click sets a X
○  s            Square has state
│ ○  o          Play instructions
│ ○  kx         Play manual
├─╯
○  n            Square is interactive
~

Unmerging with abandon

Otherwise, you could jj abandon the merge Change. Give it a try. Let's start over:

$ jj redo

Yes! You can redo an undo. Jujutsu's undo works like Emacs': rather than just going back in time, it appends the revert to an operation log, so no information is ever lost. If you are curious, read about it in Emacs' Undo.
You are back to:

@    vz         empty Here's the merge
├─╮
│ ○  o          Play instructions
│ ○  kx         Play manual
○ │  zx         Click alternates Xs and Os main
○ │  vv         Click sets a X
○ │  s          Square has state
├─╯
○  n            Square is interactive
~

Now, do yourself a favour: move somewhere else before deleting the merge, or you'll be abandoning your Current Change¹:

$ jj edit n

○    vz         empty Here's the merge
├─╮
│ ○  o          Play instructions
│ ○  kx         Play manual
○ │  zx         Click alternates Xs and Os main
○ │  vv         Click sets a X
○ │  s          Square has state
├─╯
@  n            Square is interactive
~

Now your turn.

• Unmerge, without using undo.
• Then create a new merge, this time between 3 commits: zx, o and n.

$ jj abandon vz

○  zx           Click alternates Xs and Os main
○  v            Click sets a X
○  s            Square has state
│ ○  o          Play instructions
│ ○  kx         Play manual
├─╯
@  n            Square is interactive
~

$ jj new -r zx o n

@      u       empty
├─┬─╮
│ ○ │  o                Play instructions
│ ○ │  kx               Play manual
│ ├─╯
○ │  zx         Click alternates Xs and Os main
○ │  v          Click sets a X
○ │  s          Square has state
├─╯
○  n            Square is interactive
○    ru         Board() invokes Square()
├─╮
○ │  ym         fix name: Square -> Board
○ │  x          WIP delete me
○ │  yz         LICENSE
○ │  ws         A board full of X
├─╯
○  kk           Displays X X
○  wx           Fails
○  rx           Scaffold applicatio
◆  zz      🔒   empty

In Git, undoing a merge ranges from easy to painful, depending on your experience. I hope you see how Jujutsu makes it trivial regardless.

1. Abandoning the Current Change is perfectly legit, but the first time the behavior might surprise you. If you are curious, read more about this in Pulling the Rug Out Under Oneself ↩

On Not Being There

A quick thought, before moving to more exciting features.

What's the Git command for merging the branch A with the branch B? Those who mostly use IDE plugins and rarely touch the terminal might answer, caught off guard:

git merge A B

The correct answer is:

Why Is It Like That?

Why isn't it git merge A B? Why do commands like cherry-pick, rebase, pull and am assume the current branch as an implicit argument?

Because of conflicts. When something goes wrong, Git cannot store the result as a commit. It stops and asks you to resolve the problem first, and the only place where you can do that is the file system. So, you have to be there.

And Jujutsu?

You probably noticed: when merging with Jujutsu you don't have to be anywhere in particular. You select the parents A and B without being in either. You also abandon Changes from a distance. You can even commit from a distance.

This follows from the fact Jujutsu handles conflicts as first-class citizens. You'll learn what a lifesaver this is later on but, for now, just get the gist: you can operate on Changes without being there.

It's History all the way down

Back to The Start

For the next sections I will ask you to obtain a fresh copy of the same repo you cloned before. There are at least two ways to do this.

1. You could delete the project directory and clone the repository again with:

$ jj git clone https://codeberg.org/arialdo/jj-playground1.git
$ cd jj-playground1
$ jj bookmark track '*' --remote origin

2. Otherwise, you could keep running jj undo until you get the status right after you executed that:

jj git remote remove origin

But first, you might wonder where undo and redo fetch their information from. The next few pages will shed some light on the topic.

History of a Change

Every Change has its History.

Do this little exercise. Target any Change you like, such as n:

$ jj log

@  p            empty
○  zx           Click alternates Xs and Os main
○  v            Click sets a X
○  s            Square has state
│ ○  o          Play instructions
│ ○  kx         Play manual
├─╯
○  n            Square is interactive
○    ru         Board() invokes Square()
├─╮
○ │  ym         fix name: Square -> Board
○ │  x          WIP delete me
○ │  yz         LICENSE
○ │  ws         A board full of X
├─╯
○  kk           Displays X X
○  wx           Fails
○  rx           Scaffold applicatio
◆  zz      🔒   empty

Make some modifications to it, like:

• Update its description
  • jj desc -r n -m foo
  • jj desc -r n -m bar
  • jj desc -r n -m baz
• Check it out and edit some files:
  • jj edit -r n
• Add a Change before it:
  • jj new -B n

Under the hood, each of those operations creates a new Git commit. Each time, Jujutsu makes sure the immutable Change ID n points to whichever commit is the most recent one. Throughout its existence, n goes through different states, each a different Git commit. n was born as commit 27ea11. Then it evolved to a different commit, then another, and so on. In a sense, n has its own history tree.

This isn't merely a metaphor. You can actually display that history with evolog:

jj evolog -r n

  ○  nvokxlrr arialdo@ik.me 2026-06-12 22:52:51 c655c8d7
  │  baz
  │  -- operation 2e1a28a42c55 abandon commit 668d65f4f0eea395a4c3d0a7ed890254a60865d4
  ○  nvokxlrr/1 arialdo@ik.me 2026-06-12 22:52:45 6e2c1c9a (hidden)
  │  baz
  │  -- operation 500080ebf19a new empty commit
  ○  nvokxlrr/2 arialdo@ik.me 2026-06-12 22:52:39 983a1599 (hidden)
  │  baz
  │  -- operation 3075743719f1 describe commit 22c5df185272af6f25b1d4227cd271971aa1baa5
  ○  nvokxlrr/3 arialdo@ik.me 2026-06-12 22:52:37 22c5df18 (hidden)
  │  bar
  │  -- operation 3daa0e64a476 describe commit 21a546e29d1cfcebdc0aafd8023c3d60416bff88
  ○  nvokxlrr/4 arialdo@ik.me 2026-06-12 22:52:34 21a546e2 (hidden)
  │  foo
  │  -- operation 4c7fc048be20 describe commit a857703785c7971ec20ccd826e36557f8b7d5a72
  ○  nvokxlrr/5 arialdo@ik.me 2026-06-12 22:52:28 a8577037 (hidden)
  │  Foo
  │  -- operation a6df8a6d9206 describe commit 03e16e725052f4ba32bb0a1a31a029860a86519a
  ○  nvokxlrr/6 arialdo@ik.me 2026-06-10 14:33:07 03e16e72 (hidden)
     Square is interactive

Consider this the meta-repository that tracks the history of n. Its commits are called n/1, n/2 etc. There's nothing special about these commits: you use them in commands just like any other. Meaning: you don't need to learn new special commands, like with Git reflog.

Want to inspect the changes stored in n/5?

In many cases, you'll use this meta-history to recover files you want to restore.

The History Beneath the History

If every change has its own history, then your whole repository has its own history. It's only logical. Your repo:

• In an initial stage (let's call it 000000000000) did not exist at all.
• Then it was created.
• Then you added a Change.
• Then you edited a description.

and so on.

Jujutsu is stubborn, it remembers everything, since almost every command, including jj log, triggers a working-copy snapshot.

Inspect that meta-history with:

jj op log

  ○  3075743719f1 arialdo@mbuto default@ 19 minutes ago, lasted 22 milliseconds
  │  describe commit 22c5df185272af6f25b1d4227cd271971aa1baa5
  │  args: jj describe -r n -m baz
  ○  3daa0e64a476 arialdo@mbuto default@ 19 minutes ago, lasted 24 milliseconds
  │  describe commit 21a546e29d1cfcebdc0aafd8023c3d60416bff88
  │  args: jj describe -r n -m bar
  ○  4c7fc048be20 arialdo@mbuto default@ 19 minutes ago, lasted 23 milliseconds
  │  describe commit a857703785c7971ec20ccd826e36557f8b7d5a72
  │  args: jj describe -r n -m foo
  ○  a6df8a6d9206 arialdo@mbuto default@ 19 minutes ago, lasted 21 milliseconds
  │  describe commit 03e16e725052f4ba32bb0a1a31a029860a86519a
  │  args: jj describe -r n -m Foo
  ○  192c30f0cf47 arialdo@mbuto default@ 3 hours ago, lasted 5 milliseconds
  │  restore to operation 281b30d872a33f3dc6f93982343ab3fa4d2a4adb8b3bb4903421d84003d96e96e266d90bc4e6990526d8c5eea62423b19395d5f6d2639b6be26b77d301958274
  │  args: jj op restore '000000000000+++++'
  ○  2a2be2f2b8fc arialdo@mbuto default@ 3 hours ago, lasted 5 milliseconds
  │  restore to operation 8eea9aa811a1ed9ffd6e795d17573e77caad0ddf41c716489fbe8e7526aad797c10b2cbc4c45de0845b7e1f84c6a458f148e6eab9c1241fa72d7f62c1a2f89d3
  │  args: jj op restore '000000000000++++'
  ○  281b30d872a3 arialdo@mbuto default@ 3 hours ago, lasted 4 milliseconds
  │  remove git remote origin
  │  args: jj git remote remove origin
  ○  8eea9aa811a1 arialdo@mbuto default@ 3 hours ago, lasted 14 milliseconds
  │  check out git remote's branch: main
  │  args: jj git clone https://codeberg.org/arialdo/jj-playground1.git
  ○  eff465d67569 arialdo@mbuto default@ 3 hours ago, lasted 2 seconds
  │  fetch from git remote into empty repo
  │  args: jj git clone https://codeberg.org/arialdo/jj-playground1.git
  ○  ee32fa88d5f2 arialdo@mbuto default@ 3 hours ago, lasted 3 milliseconds
  │  add git remote origin
  │  args: jj git clone https://codeberg.org/arialdo/jj-playground1.git
  ○  23c04169eec1 arialdo@mbuto 3 hours ago, lasted 6 milliseconds
  │  add workspace 'default'
  ○  000000000000 root()

As expected, everything originates from 000000000000, the origin of times. From there you can travel through all the commands you ran. Each command created a snapshot of the whole repository.

It's a repository of your repository's history.

Rewind!

Restoring the repository exactly as it was before an operation is trivial. Each operation has its ID which you can reference with the command jj op restore.

You want to go back to when you performed:

jj git clone https://codeberg.org/arialdo/jj-playground1.git
cd jj-playground1
jj bookmark track '*' --remote origin

$ jj op restore 000000000000+++++

Check the file system and the history log: everything is back to the moment you cloned the repo.

Like Emacs, Jujutsu Never Forgets

If you inspect the output of jj op log you will find that your last jj op restore has been appended to the top of all the other operation logs. So, you can still undo it by restoring its parent.

Basically:

• Every operation, including op restore and undo, appends a full snapshot to the op log.
• op restore reproduces an old snapshot and appends the result to the history.
• undo restores the previous op.

We've all dreaded performing risky operations in Git. Armed with these tools, you should never feel that way again.

Ready?

After:

$ jj op restore 000000000000+++++

your repo should be:

  ○  zx       Click alternates Xs and Os main
  ○  v        Click sets a X
  ○  s        Square has state
  │ ○  o        Play instructions
  │ ○  kx       Play manual
  ├─╯
  ○  n        Square is interactive
  ○  ru       Board() invokes Square()
  ├─╮
  ○ │  ym       fix name: Square -> Board
  ○ │  x        WIP delete me
  ○ │  yz       LICENSE
  ○ │  ws       A board full of X
  ├─╯
  ○  kk       Displays X X
  ○  wx       Fails
  ○  rx       Scaffold applicatio
  ◆  zz   🔒  empty

Good. You are ready to play with rebase and squash.

Moving Things Around

You can do all sort of black magic sorcery with just 2 commands:

Best of all, they only take a few minutes to learn.

Moving Changes

rebase works like this:

• you specify which Changes you want to move
• and where you want to move them.

Simply:

rebase -r X -o Y

moves the Change X on top of Y. You can also specify the destination using the same --before / -B and --after / -A options you used with jj new.

You'll find the sample repository has many mistakes and unfinished work. I will invite you to fix all the problems in the next exercises.

First, the License

Oh, no! I've added the license to the repository a bit too late, in the Change yz:

  @  x        empty
  ○  zx       Click alternates Xs and Os main
  ○  v        Click sets a X
  ○  s        Square has state
  │ ○  o        Play instructions
  │ ○  kx       Play manual
  ├─╯
  ○  n        Square is interactive
  ○  ru       Board() invokes Square()
  ├─╮
  ○ │  ym       fix name: Square -> Board
  ○ │  x        WIP delete me
  ○ │  yz       LICENSE
  ○ │  ws       A board full of X
  ├─╯
  ○  kk       Displays X X
  ○  wx       Fails
  ○  rx       Scaffold applicatio
  ◆  zz   🔒  empty

$ jj show --summary yz
  Commit ID: 997391344e0b704d8ad78a51e8b9d8c367dc6998
  Change ID: yzxvwmnznuxqpsqttxntvzuqzyrtwsww
  Author   : Arialdo <arialdo@ik.me> (2026-06-10 14:08:47)
  Committer: Arialdo <arialdo@ik.me> (2026-06-10 14:09:15)

      LICENSE

  A LICENSE

Ideally, I would add the license as the very first commit. Somehow yz ended up in the middle of a merged branch.
Can you move yz so it becomes the initial commit?

$ jj rebase -r yz -A zz

$ jj rebase -r yz -B rx

Things Committed by Mistake

The Change x has a suspicious message: WIP: delete me. What does it contain?

$ jj show x --summary
  Commit ID: 22014d7c4604eb00430fe4e7a583e9aaf5afb77e
  Change ID: xxuknwmlponouxznpzmnqxqvrooxttru
  Author   : Arialdo Martini <arialdo.martini@gmail.com> (2026-06-13 15:46:46)
  Committer: Arialdo Martini <arialdo.martini@gmail.com> (2026-06-13 16:09:31)

      WIP delete me

  A node_modules/yaml/LICENSE
  A node_modules/yaml/index.js

How to get rid of it?

$ jj abandon x

Why this exercise? It seems unrelated to moving stuff. But Jujutsu did rebase all descendants of x onto yz under the hood.
Moving things doesn't always look like moving things: Jujutsu commands capture your intent, not the underlying operations.

Typos

Now that I notice, there's a typo in rx's message: applicatio instead of application.
How would you fix it?

$ jj desc -r rx -m "Scaffold application"
Rebased 13 descendant commits
Working copy  (@) now at: xxuknwml 770ae789 WIP delete me
Parent commit (@-)      : yzxvwmnz 02b946ad LICENSE

Again: the intent is editing a message. The log message Rebased 13 descendant commits reveals that, under the hood, it's still about moving commits.

Let's see other examples where your intent is really moving Changes.

A Glimpse of the Revset Language

With Git you are probably used to rebasing whole branches. Jujutsu's rebase makes no assumptions about what you want to move.

You already saw how to rebase a single Change; you can just as easily move multiple Changes, even sparse ones across different branches: just specify them. For example:

jj rebase -r X -r Y -o O

would move both X and Y on top of O.
Instead of listing Changes one by one, you can use expressions in the Revset Language. Here's a foretaste:

Each expression returns a set, so you can keep combining them into more complex ones.

Moving Sets of Changes

Say that for whatever reason, you want to move the license (Change yz) and the manual (Changes kx and o) on top of main.

  @  t        empty
  ○  zx       Click alternates Xs and Os main  <-- move them here
  ○  v        Click sets a X
  ○  s        Square has state
  │ ○  o        Play instructions              <-- this
  │ ○  kx       Play manual                    <-- this
  ├─╯
  ○  n        Square is interactive
  ○  ru       Board() invokes Square()
  ├─╮
  ○ │  ym       fix name: Square -> Board
  ○ │  x        WIP delete me
  ○ │  ws       A board full of X
  ├─╯
  ○  kk       Displays X X
  ○  wx       Fails
  ○  rx       Scaffold application
  ○  yz       LICENSE                          <--- this
  ◆  zz   🔒  empty

jj rebase -r yz -r kx -r o -o zx

jj rebase -r "yz | kx | o" -o zx

Before moving to the next exercise, just:

jj undo

this last move, please.

Rebasing a Branch

If you run jj undo from the previous page, your history tree should be:

  ○  zx       Click alternates Xs and Os main        <--- this branch
  ○  v        Click sets an X
  ○  s        Square has state
  │ ○  o        Play instructions
  │ ○  kx       Play manual
  ├─╯
  ○  n        Square is interactive
  ○  ru       Board() invokes Square()
  ~

How would you rebase the branch from s to zx on top of o?

$ jj rebase -r "s::zx" -o o

You should get to:

  ○  zx       Click alternates Xs and Os main
  ○  v        Click sets an X
  ○  s        Square has state
  ○  o        Play instructions
  ○  kx       Play manual
  ○  n        Square is interactive
  ○  ru       Board() invokes Square()
  ~

How would you undo that, using rebase and not undo?

$ jj rebase -r "s::zx" -o n

○  zx       Click alternates Xs and Os main
○  v        Click sets an X
○  s        Square has state
│ ○  o        Play instructions
│ ○  kx       Play manual
├─╯
○  n        Square is interactive
○  ru       Board() invokes Square()
~

Give yourself a pat on the back if you got it right.

Rebasing 2 Branches Simultaneously

On top of n we have 3 branches (I'll name them by their tip Change ID):

• rt, which introduces CSS.
• zx, where new functionalities are.
• o, which contains the manual.

  ○  rt       Minimal CSS css                     <- this
  │ ○  zx       Click alternates Xs and Os main   <- this
  │ ○  v        Click sets an X
  │ ○  s        Square has state
  ├─╯
  │ ○  o        Play instructions manual          <- this
  │ ○  kx       Play manual
  ├─╯
  ○  n        Square is interactive
  ~

We decide to include CSS in the other 2 branches. So, your goal is to rebase both zx and o on top of rt.
You could do this with:

    jj rebase -r kx:: -o rt

followed by

    jj rebase -r s:: -o rt

Would you be able to do this in 1 command?

jj rebase -r 'kx:: | s::' -o rt
  
○  zx       Click alternates Xs and Os main*
○  v        Click sets an X
○  s        Square has state
│ ○  o        Play instructions manual*
│ ○  kx       Play manual
├─╯
○  rt       Minimal CSS css
│ ~
├─╯
○  n        Square is interactive

Rebasing multiple branches is especially handy for keeping them up to date with trunk. Check out rebase-all, an alias by Steve Klabnik, you'll love it: you just run jj rebase-all so your local work is always based on the latest main.
People invented all sorts of amazing aliases: find them at https://github.com/jj-vcs/jj/discussions/8484.

Preview of Revsets

You should never fear a rebase: after all, you can always resort to jj undo. Also, you can always obtain a preview of the Changes involved in a Revset expression using log:

   jj log -r 'kx:: | s::'
   ○  zx       Click alternates Xs and Os main*
   ○  v        Click sets an X
   ○  s        Square has state
   │
   ~

   ○  o        Play instructions manual*
   ○  kx       Play manual
   │
   ~

Universality of Revsets

Oh, and by the way: once you have defined a Revset expression, you can use it with many commands:

• Want to delete all those Changes? jj abandon -r 'kx:: | s::'
• Want to inspect all of them? jj show -r 'kx:: | s::'
• Want to change their author? jj metaedit -r 'kx:: | s::' --update-author "Joe Doe"

That's a general trait: Jujutsu has few building blocks, but they combine in countless ways.

Moving Edits Around

Changes and Edits

A Change contains your modifications to files such as adding a class, renaming a function, and the like. You can see them as the diff shown by jj show (use --git if you want to use the Git format):

$ jj show rt --git
Commit ID: ad4aa4890ec32cf83c51a407a099afaf9af106b9
Change ID: rtsytxmrmouvklxkuuvqxolokmmkzssz
Author   : Arialdo <arialdo@ik.me> (2026-06-13 19:05:31)
Committer: Arialdo <arialdo@ik.me> (2026-06-15 08:10:28)

    Link to CSS

diff --git a/public/index.html b/public/index.html
index efd73153a2..fd6a1cbbfe 100644
--- a/public/index.html
+++ b/public/index.html
@@ -4,6 +4,7 @@
     <meta charset="UTF-8">
     <meta name="viewport" content="width=device-width, initial-scale=1.0">
     <title>Document</title>
+    <link rel="stylesheet" href="index.css">
   </head>
   <body>
     <div id="root"></div>

The Jujutsu manual calls them "changes", but that term is already overloaded. Let me call them "edits" from now on, OK?

Finding the Source of a Typo

To narrow down jj log to some files, you can use the Revset Language function files(). Here's the change history of README.md:

$ jj log -r "files('README.md')"

○  kk           Displays X X
~  (elided revisions)
○  rx           Scaffold application
│
~

As you see, README.md was created in rx and modified in kk. Inspect what kk is about:

$ jj show kk --git

diff --git a/README.md b/README.md
index d8ce899bb8..ec822c4346 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,3 @@
-# Learning Raect.js
+# Learning React.js

diff --git a/src/App.js b/src/App.js
index 3f8dbe3702..495f426244 100644
--- a/src/App.js
...

Uh oh! Together with a change to the JavaScript code in App.js, there's also a little fix to the word React.js in README.md. If you check the content of rx, you will see it's the one that introduced the typo:

$ jj file show -r rx README.md
# Learning Raect.js

Following the tutorial at https://react.dev/learn/tutorial-tic-tac-toe

So, it must have gone like this:

• I wrote the typo Raect instead of React in rx.
• I missed that so I kept building on top of that.
• Then, while I was coding App.js I stumbled upon the typo.
• Instead of fixing it by amending rx, I created a Change, kk, mixing the typo fix with other unrelated changes.

Silly me...
How to move the fix Raect.js -> React.js from kk to rx?

This is really about moving edits.

Sending Fixes Back to the Past

Rebase won't help here: you don't want to move the Change kk, but the edits it contains.
Enter squash. If you are familiar with git merge --squash and the git rebase --interactive's squash command, you know that squashing in Git is about combining multiple commits into a single one.

jj squash generalizes this concept. Think of it as a way to transfer edits from one Change to another. Though these concepts may seem unrelated, Jujutsu's squash is general enough to cover both. The basic syntax is:

jj squash --from A --into B [FILES]

or more concisely:

jj squash -f A -t B [FILES]

The net effect: the edits to [FILES] move from A to B. Your edits stay the same; only which Change owns them differs.

So, fixing my mess with Raect.js is a matter of running:

$ jj squash -f kk -t rx README.md

Check the content of kk:

$ jj show --summary kk

Commit ID: 3c72f2573cc5235622030aac110e884014e8ec6b
Change ID: kkqvwlzrztzvlmtyqksulvyuwsorpppx
Author   : Arialdo <arialdo@ik.me> (2026-06-10 14:02:12)
Committer: Arialdo <arialdo@ik.me> (2026-06-15 14:50:39)

    Displays X X

M src\App.js

README.md is not listed anymore. Indeed, in rx the typo is gone:

$ jj file show -r rx README.md
# Learning React.js

Following the tutorial at https://react.dev/learn/tutorial-tic-tac-toe

because the typo fix has been absorbed by the edits already there.

Cool! Next time you are focused on some development task and you find a typo in an unrelated file, you can fix it on the spot and then send it back to the past, where it belongs.

Dispatching Edits from Megamerges

Why did I say "absorb" in the previous chapter? Because you could have done that squash using jj absorb. Run a jj undo and give it a try. Go to kk:

jj edit kk

and run:

jj absorb README.md

jj absorb will accomplish what you just did manually: it will identify the source of the typo and will move the edit there.

If you don't specify the file, jj absorb will analyze all the edits you did. For each individual edit, it will figure out the closest ancestor it can safely land in. Got multiple edits across multiple files? No problem: jj absorb will split them apart and dispatch each one to its rightful Change back in your history.

If you are anything like me, you're probably grumbling: "no way this works without breaking something". I swear I thought the same, and I swear that Jujutsu proved me wrong.

Is it safe?

First of all, you always have jj undo.
Besides this, yes, it is: jj absorb is very conservative: when the destination Change can't be unambiguously determined, jj absorb does nothing rather than risk a mess.

When Do You Use It?

Remember the Megamerge Workflow I told you about in Intermezzo: A Taste Of a Fanciful Workflow? That's the typical case where jj absorb shines.

The idea is: you have multiple Pull Requests waiting to be merged:

○
○
○
│
│ ○
│ ○
│ ○
├─╯
│ ○
│ ○
│ ○
├─╯
○
◆

and over time you receive feedbacks on them. Rather than jumping left and right to fine-tune your code, you create an octopus merge of all your PRs, the megamerge, and you sit on top of it, in a new empty Change:

@     <- Your staging area
○     <- The megamerge
├─┬─╮
│ │ ○
│ │ ○
│ │ ○
│ │ ○
│ ○ │
│ ○ │
│ ○ │
│ ├─╯
○ │
○ │
○ │
├─╯
○
◆

This lets you work on all your branches from a single staging area.

How does it work? As feedback comes in on one of your Pull Requests, you make the necessary change directly on top of the megamerge, which contains the sum of all your work; then you use jj absorb to dispatch the change where it belongs.

You won't have to worry about merge conflicts, because:

• jj absorb would stop rather than creating one.
• The megamerge already proves all your PRs work together, so conflicts are caught early by design.

You can read more about this workflow in the following two articles. There's a video in the first one if you want to see how this works in practice.

• Isaac Corbrey - Jujutsu megamerges for fun and profit

• Chris Krycho -Jujutsu Megamerges and jj absorb

• Steve Klabnik - Steve's Jujutsu Tutorial - Working on all of your branches simultaneously

Hammers and Nails

Allow me a brief reflection.

The language we use defines the boundaries of what we can think.

The same applies to the tools and the programming languages we use. By making some operations easy and others hard, they make some concepts thinkable and others invisible.

A workflow requiring 40 fragile steps in Git isn't just avoided: it ceases to exist as a mental category. My thesis is that implementation difficulty leads to conceptual absence. Or, as my grandma would say:

What's hard to do becomes hard to think.

Jujutsu illustrates this point beautifully. Megamerge has always been technically achievable in Git, hasn't it? Yet nobody invented it. Why? Because it required a chain of operations so convoluted that it was just too hard to even ideate them.
By elevating its interface from implementation details to intent, Jujutsu turned some convoluted operations into trivial ones, and this allowed people to envision new workflows.

I'm standing on the shoulders of giants with this thought. Ken Iverson, the APL's creator, titled his 1979 Turing Lecture Notation as a Tool of Thought arguing exactly that: notation doesn't carry preexisting thoughts but shapes them.

The first corollary is that the limits of our tools (and our thought!) are invisible from the inside. Remember that I cited Graham's Blub Paradox? It states that we can see what's missing from poorer languages, but not what's missing from ours, compared to more powerful ones.

My personal corollary is maybe counterintuitive (and not necessarily compatible with your career ambitions): always deliberately expose yourself to tools and languages you'll never seriously use. Maybe you will never switch to them, but the space of what will be conceivable by your fantasy will never be the same.

We've always thought in Git. Jujutsu expands the boundaries of our thought. I hope to live long enough to see what will come next.

Moving Chunks Around

jj absorb can dispatch multiple edits within a single file to different Changes. So far, you've only learned to use jj squash -f FROM -t TO FILES, which moves all the edits in the given files at once. But moving every edit in a file is not necessarily what you want. Usually you need to be more selective.

See this case, for example:

$ jj show ym --git

    fix name: Square -> Board

diff --git a/src/App.js b/src/App.js

--- a/src/App.js
+++ b/src/App.js

-// Main apication
+// Main application
...
-export default function Square() {
+export default function Board() {

The main goal of the Change was to rename a function from Square() to Board(). Mixed with this, though, I also fixed another typo (again!): apication -> application.

The line // Main apication was introduced by Change rx. Doing:

$ jj squash -f ym -t rx src/App.js

is too coarse, it would drag the Square() -> Board() rename into rx as well, which is not what you want. jj absorb would work, but there are alternatives which give you more control.

Interactively Select Chunks

Use the --interactive / -i option of jj squash:

jj squash -f ym -t rx -i

An interactive editor will open, with which you can select which chunk to include in the squash:

[File] [Edit] [Select] [View]
( ● ) src\App.js

[●] Section 1/2
  [●] - // Main apication ⏎
  [●] + // Main application ⏎
       2 // Display a 3x3 board and let the user ⏎
       3 // play Tic Tac Toe ⏎

[ ] Section 2/2
  [ ] - ⏎
  [ ] - export default function Square() {⏎
  [ ] + ⏎
  [ ] + export default function Board() {⏎
       6   return ( ⏎
       7     <> ⏎
       8       <div className="board-row"> ⏎
             ⋮

You can use the following keys:

You can also use -i to select whole files: that's often a convenient alternative to listing file names in jj squash -f FROM -t TO FILES.

Building On Top Of Squash

By now, you should have got a solid grip on squash. In combination with rebase, it's one of the sharpest tools in the box.

Take a breath and look at the range of operations now at your fingertips. Odd are, you are already doing things you've never attempted with Git. Be proud of yourself.

It's time for you to see the Squash Workflow, a popular, idiomatic Jujutsu workflow. After this, you won't miss Git's index anymore.

Squashing Changes

The way jj squash parameter defaults interact is quite clever.The basic syntax is:

jj squash -f A -t B FILES

• If you omit the list of files, then all the changes in the Change are moved.
• If you omit either -f or -t, then the Current Change @ will be implied.

So:

jj squash -f z

moves the edits from z to your current working copy.
If you do:

jj squash -t x

your edits move to x, no matter where it sits in your history, either in the past or in the future, in the same branch or elsewhere.

This technique is truly powerful: it lets you edit something here and send it somewhere else when you're done.
For example, if you notice an unrelated typo while working on a feature, fix it on the spot and squash it where it belongs.
Or, say you spot something that needs to be done in a different branch. You can write the change immediately and then move it there with a jj squash. In a sense, this is the basic move that lets you work on multiple features simultaneously.
These moves are so idiomatic that Jujutsu offers a "macro command": absorb. I'll cover it in the following pages with practical exercises.

Abandoning Changes

When the source Change is left empty after a move, Jujutsu automatically abandons it. For example, say you have:

$ jj log -r "n::zx"

○  zx
○  v
○  s
○  n

If you squash v into n:

then you end up with:

○  zx
○  s
○  n

What Happens To Messages?

As with Git, Jujutsu always preserves information. If squashing results in deleting a Change, and that Change has a description, Jujutsu will stop and interactively let you define one. You will typically merge all the original messages into one.
Otherwise, you can always set the message with -m, or use --use-destination-message / -u.

Quiz Time!

Check out this sloppy mistake:

$ jj show yo- --git

--- a/src/App.js
+++ b/src/App.js
...
+    <button
+      className="square"
+      onClick={handleClic}
...

Oops, Clic instead of Click. Have I fixed it in yo-? Not at all! I committed a fix on top of it, with the very expressive message "Fix":

$ jj show yo --git

--- a/src/App.js
+++ b/src/App.js
@@ -11,7 +11,7 @@
   return (
     <button
       className="square"
-      onClick={handleClic}
+      onClick={handleClick}
     >

Terrible. Help me, please: get rid of that noisy yo Change and make yo correct:

jj edit yo
jj squash -u

Just jj squash

If you run the bare jj squash, without any argument, then:

• it will move all the changes (indeed, no files are specified)
• from the Current Change to its parent.
• Should your Current Change have no message, it will be abandoned and a fresh new one will be immediately created.

Say you are on the tip of a branch:

@  sw           empty
○  zx           Click alternates Xs and Os main
○  v            Click sets a X
○  sn           Square has state

You code, editing @. Then you run jj squash.
Can you see where this goes? It's the equivalent of having the Git index!

Let me show you how this works.

The Squash Workflow

Apparently, this is the preferred workflow by Martin von Zweigbergk, the guy who invented Jujutsu. So it is probably deeply rooted in Jujutsu's philosophy.

It revolves around these 2 ideas:

• You start by committing.
• Then, you code in a disposable Change on top of your commit.

When you are done with your work, you squash down the changes. Let me just show you; it's faster than explaining.

$ jj log

○  q    Add the CSS file css
○  rt   Link to CSS
│ ○  o  Play instructions manual
│ ○  kx Play manual
├─╯
│ ○  zx Click alternates Xs and Os main
│ ○  v  Click sets a X
│ ○  s  Square has state
├─╯
○  n    Square is interactive
~

The Changes rt and q are about the CSS. Let's say that you want to improve the web page layout, adding a mouse hover effect.

First: Commit!

You start by declaring your intent, committing to a goal:

$ jj new -r q -m "Hover effect to board squares"

○  rt   empty Hover effect to board squares
○  q    Add the CSS file css
○  rt   Link to CSS
~

You haven't started coding yet, so of course the Change is empty. Eventually, it will be the next commit in your history. Think of the Git index, it's pretty much the same idea: a Candidate Commit.

Second: Set Up Your Workspace

Then build a disposable Change on top of your Candidate Commit:

$ jj new

○  xm   empty
○  rt   empty Hover effect to board squares
○  q    Add the CSS file css
○  rt   Link to CSS
~

That empty, messageless Change may seem odd, but squint a little, it's just like Git. With Git you start with:

Third: You Code

Nothing new to see here: Jujutsu reflects every file system change in your tip Change xm.

Finally: You Squash

When you're done, review and move your changes back to the Candidate Commit.

jj squash

or:

jj squash -i

if you want to do this chunk by chunk.

When jj squash completes, the now-empty tip Change is automatically abandoned and replaced with a fresh one.

Try It Out

Give it a try. Say you want to add:

.square:hover {
  background: #e0f7fa;
  cursor: pointer;
  transition: background 0.2s;
}

to style.css. Your turn!

jj squash -i

Moving Edits To The Future

You saw how to send an edit back to a past Change. In fact, there is nothing in the --from and --into options of jj squash that constrains their position in the history tree. You can send edits to the past, to the future, even to unrelated branches.
But why would you send edits to the future?

A common use case is the following. Inspect the Change rv: it contains 2 unrelated edits, one to CSS and one to the logic:

○  kt   empty Hover effect to board squares
○  rv   Changes to both CSS and app.js
○  q    Add the CSS file css
~

How would you split that Change in two? A possible approach is:

• To create a Change after rv.
• To move part of the edits of rv in that future Change.

Come on, try it yourself. Split the CSS edits from the app.js edits into 2 separate Changes:

$ jj desc -r rv -m "Changes to CSS only"
$ jj new -A rv -m "Changes to app.js only"
$ jj squash -f @- -i

Split

This move is so common that Jujutsu offers a macro command: jj split. It is equivalent to creating a new Change, either after (-A) or before (-B), and then running a jj squash -i.

jj undo the previous move and do it again with jj split.

Copying Files

Good things always come in threes. You have met jj squash and jj rebase; meet jj restore. All for one and one for all: together those three musketeers are all you need to bend the history tree to your will:

jj restore is a command for copying file contents, and it shares the same syntax as jj squash (have I already told you that Jujutsu is consistent?)

jj restore -f FROM -t TO FILES

This would copy the content of FILES from FROM to TO.
Think of it as copy-paste: you copy the content of FILES from FROM and paste them into TO. The original in FROM stays unmodified.
This includes deletions: if a file was deleted in FROM, it will be deleted in TO too.

As for squash, if you omit either -f or -t, the Current Change @ will be implied.
If you omit FILES, the whole working copy will be restored.

When Is It Useful?

Days ago your README.md had rich examples and beautiful ASCII diagrams. Then your PM asked for something "more executive". Fine, you trimmed it down. PMs are always right. Especially on Friday afternoon.

Today the same PM says (because of course they do): "You know what? Actually, I liked the long version better".

You sigh and call jj restore to the rescue:

• You jj log and find the Change X with message docs: README with beautiful diagrams
• jj restore --from X README.md

Done.
You see? You are not "going back in time": you are pulling a file out of an old snapshot and pasting it into the Current Change.

Is This Use Case Really That Common?

Not particularly. But like with jj squash, there are interesting consequences to the jj restore's default arguments.

Restarting

The jj restore --help page states:

When neither --from nor --into is specified, the command restores into the working copy from its parent(s).

That's a neat default! It means that:

jj restore

is equivalent to:

jj restore -f @- -t @ .

which makes the Current Change identical to its parent. It's a convenient way to clean up everything and start over.

Give it a try:

○  rt           Link to CSS
○  n            Square is interactive
○    ru         Board() invokes Square()
├─╮
○ │  ym         Rename: Square -> Board
○ │  xx         WIP delete me
○ │  yz         LICENSE
○ │  ws         A board full of X
├─╯
○  kk           Displays X X
○  wx           Fails
○  rx           Scaffold application

Select any Change you like (say: ru) and create a new Change on top of it:

jj new ru

Make any modification you like:

$ touch unnecessary.txt
$ echo "a bug" >> src/App.js
$ rm src/index.js

$ jj st
Working copy changes:
M public/index.html
M src/App.js
D src/index.js
A unnecessary.txt

2 modified files, 1 deleted and 1 added.
How to start over and get back to an empty Change?

$ jj restore
Added 1 files, modified 2 files, removed 1 files

$ jj st
The working copy has no changes.

Back to the start.

Isn't This equivalent to git restore?

Not really. In Git, the same information is spread across three layers, HEAD, the Index, and the working tree, plus the fourth grey area of untracked files. As a result, you need different commands and options depending on which subset you want to affect.

Don't Edit

In the chapter Committing you read that:

By editing the file system, you are directly editing the commit.
We will soon see how this is somewhat dangerous.

In hindsight, I was a bit dramatic. After all, Jujutsu, like Git, never deletes information, so there's nothing really dangerous.
But why let accuracy spoil good drama? So, let me reformulate the idea as follows:

Directly performing open-heart surgery on a Change with jj edit is dramatically more perilous than working from a distance, on a new Change on top of it.

Terrified? Good. (Really, you have no reason to be, but good).

What's Wrong With Editing?

jj edit is ruthless: you edit the filesystem and each and every change is unconditionally committed to the Current Change. Even worse: if you are editing a Change deep in the history tree, this will also recursively propagate the changes to all the descendants, with an automated rebase.

The problem is that not every change is intentional:

• Building the project can create artifact files. Jujutsu might track them before you get the chance to add them to .gitignore.
• We all have fat fingers, and we all make mistakes. Combine "mistakes" with "automatically and recursively propagated" and have a recipe for disaster.
• Editors and tools might create stray files. jj edit won't care: it will commit and rebase anyway.

A good rule of thumb, with Jujutsu just as with Git, is:

Always review the changes before making them part of a commit.

That's why the Git Index exists. jj edit is often just too rushed.

The solution is pretty easy: whenever you are tempted to run jj edit X, run jj new X instead. Rather than starting open-heart surgery on X (sirens blaring!), jj new prepares a safe working area for you to work in peace (elevator music...).

Mini-workflow

Here's a little recipe. If you want to edit X:

1. jj new X
2. Make your edits.
3. When you are done, review your work with jj diff and squash it back with jj squash.
4. If you want to start over, jj restore.

jj diff will show you the changes you made.
jj restore will revert only your changes, leaving the original target Change intact.

See This In Practice

Again using our sample repository. Say you want to edit v:

○  zx           Click alternates Xs and Os main
○  v            Click sets a X                    <-- What you want to edit
○  s            Square has state
│ ○  kt         empty Hover effect to board squares
│ ○  rv         empty Changes to both CSS and app.js
│ ○  q          Add the CSS file css
│ ○  rt         Link to CSS
├─╯
│ ○  o          Play instructions manual
│ ○  kx         Play manual
├─╯
○  n            Square is interactive
~

Instead of jj edit v, go with $ jj new v:

@  l            empty                             <-- Your Current Change
│ ○  zx         Click alternates Xs and Os main
├─╯
○  v            Click sets a X                    <-- What you want to edit
○  s            Square has state
│ ○  kt         empty Hover effect to board squares
│ ○  rv         empty Changes to both CSS and app.js
│ ○  q          Add the CSS file css
│ ○  rt         Link to CSS
├─╯
│ ○  o          Play instructions manual
│ ○  kx         Play manual
├─╯
○  n            Square is interactive
~

Notice where you landed:

• on an empty, messageless Change
• on top of the Change you want to edit.

Let me call that empty Change the Buffer Change.

If you squint, you could think of that Buffer Change as a Git Index-like structure. Only, it's an ordinary Change, like all the other ones, so it's persistent and operable with the ordinary commands.

Isn't That The Same As jj edit?

Definitely no.
If you did jj edit v directly:

• jj diff would display your changes plus all the changes originally in v, mixed together. Reviewing your work would be less convenient.
• Similarly, jj restore would revert your changes plus all the changes originally in v, basically reverting everything to v's parent s: definitely, not what you want.

The Joy Of Not Having Special Cases

The fact this Buffer Change is an ordinary Change has a couple of interesting consequences.

There's No Need for jj stash

You need to drop everything and switch to something else:

• With Git, before running git checkout, you need to git stash push or you will lose your work.

• With Jujutsu? Fear no more: go safe with jj new somewhere else: your Buffer Change won't be lost.

Since you are working with ordinary Changes, there's no separate stash mechanism to learn: suspended work lives alongside all other Changes and never gets lost. The git stash machinery collapses into the Jujutsu primitives you already know.

Multiple Indexes

Have you ever thought you can have multiple indexes? Say that while you are editing v (from a distance) you come up with another possible approach to complete your work. No problem: run another jj new v and you'll end up with a second, independent Index-like Change. Eventually, you will jj abandon one and jj squash the other. Or maybe you want to mix them? Your choice.

Wandering Around

When you run jj new and you land in a new Change, if the Change you left behind is empty, Jujutsu abandons it.

That's a particularly happy default: it implies that you can jump back and forth in your history tree targeting different Changes with jj new.

Target X and run jj new X: by design, the new Change you jump to has the same content that X has. So, you can use it as a safe copy to see what's inside X, replicating its content on your disk.

By sitting on top of the Change you want to visit, you are sure that:

• You won't pollute the history with empty leftover Changes.
• There's no risk of unintentional modifications.

In practice, this is a very cheap way to get read-only access to your repository.

Conflict Resolution

Enough with the easy cases. Let's talk about the exact opposite situation.

The mini-workflow (jj new && (jj squash | jj revert)) you saw in the previous page is particularly handy when resolving conflicts.
So, it's definitely time to tackle this topic.

Conflicts

We will spend quite a bit of time on this topic. Not because it's tricky, but because it's one of the scariest topics in Git, and I'm determined to put that fear to rest once and for all.

We will play with conflicts in practice, with a real repository. Clone it with:

jj git clone https://codeberg.org/arialdo/jj-playground-conflicts.git

Then, as before, create a tracked local branch for each remote branch:

jj bookmark track '*' --remote origin

You haven't seen the first command before: it creates a local bookmark for each remote branch. We'll see bookmarks in a few pages.

Here's the history tree:

@  mv   hello mundo
│ ○  nz hola world
├─╯
○  vr   hello world
○  ypl
○  vw
│ ○  nl
│ ○  ypy
│ ○  mw
│ ○  ww
│ ○  wq
├─╯
○  x
○  vn
○  r
│ ○  no  feat-1
│ ○  vt
│ ○  s
│ ○  u
│ ○  vz
├─╯
○  q
◆  z

Ready to go! We will do the following moves, each producing some conflicts, progressively more challenging (but I swear: they are all trivial):

1. We merge mv and nz to get a merge conflict.
2. Then we rebase the branch feat-1 to get 1 single rebase conflict.
3. Then the branch feat-2, to get multiple conflicts.

Then, we will play with some novel conflict resolution techniques that are just not available with Git.

Ready? Hands on the keyboard!

Focus on the Changes:

○  nz        merge-b
│ ○  m         merge-a
├─╯
○  vr       Base of merge-a and merge-b
│
~

They have vr as their shared base. vr contains a text file with some Lorem Ipsum lines. Among them, you'll find the line:

We will create a conflict here.

If you inspect m / merge-a:

jj show m

you see that it edits exactly that line, adding:

: merge-a added this text.

By the way: you can also reference m using the bookmark merge-a. Bookmarks are equivalent to Git's branches.
The Change nz / merge-b does the same, only with the text:

: merge-b added this text.

Since the two changes are incompatible, merging them will certainly result in a conflict.
Exactly what we want!

○  nz        merge-b
│ ○  m         merge-a
├─╯
○  vr       Base of merge-a and merge-b
│
~

So, let's create this conflict. Merge merge-a and merge-b, with the message Merge conflict. Do you remember how to merge branches?

jj new merge-a merge-b -m "Merge conflict"

jj new a nz -m "Merge conflict"

jj new merge-b merge-a -m "Merge conflict"

jj new nz a -m "Merge conflict"

Jujutsu will let you know you have a conflict:

Working copy  (@) now at: nlpwoyvx 0670a921 (conflict) (empty) (no description set)
Parent commit (@-)      : mvxxwqoo e1acf668 merge-a | (no description set)
Parent commit (@-)      : nzsunxwp 0004a47a merge-b | (no description set)
Added 0 files, modified 1 files, removed 0 files
Warning: There are unresolved conflicts at these paths: file.txt    2-sided conflict

Notice: it's warning, not an error. When you are in a conflicted Change, jj log will display the @ marker in red. Any other conflicted Change will be displayed as a red ×.

As we've noted before, having a conflict won't prevent you from continuing your work.
Let's challenge this notion.

Living with Conflicts

Let's see if before resolving the conflict you can rebase the whole branch vr:: from its base q to r:

@  zo       empty Merge conflict
├─╮
│ ○  nz        merge-b
○ │  m         merge-a
├─╯
○  vr       Base of merge-a and merge-b   <- current base
│ ○  y        empty  feat-2
│ ○  vw       empty
│ ○  x        empty
│ ○  vn       empty
│ ○  r        Rebase vr:: here            <- rebase it here
├─╯
│
~

jj rebase -r vr:: -o r

The rebase succeeds. Unlike Jujutsu won't whine with something like:

error: cannot rebase: You have unstaged changes.
error: additionally, your index contains uncommitted changes.
error: Please commit or stash them.

or:

fatal: It seems that there is already a rebase-merge directory, and
I wonder if you are in the middle of another rebase.  If that is the
case, please try
        git rebase (--continue | --abort | --skip)
If that is not the case, please
        rm -fr ".git/rebase-merge"
and run me again.  I am stopping in case you still have something
valuable there.

Of course, even if jj rebase succeeded, the conflict is still there, and you will be reminded of that:

Warning: There are unresolved conflicts at these paths:
file.txt    2-sided conflict

But again, it's just a warning, not a showstopper.
Can you even commit on top of a conflicted Change? Of course, why not! Give it a try:

jj new -m "My parent is conflicted"
jj new
echo "I can keep working" > some-work-file.txt
jj squash


@  l        empty
×  zm       My parent is conflicted
×  zo       Merge conflict
├─╮
│ ○  nz        merge-b
○ │  m         merge-a
├─╯
○  vr       Base of merge-a and merge-b
│
~

As you see, Jujutsu won't forget that there is a conflict back in history, so it will keep displaying the warning:

Warning: There are unresolved conflicts at these paths:
file.txt    2-sided conflict

and jj log will highlight all the Changes inheriting that conflict using × and red @ symbols.

Time to resolve the conflict.

Resolving A Conflict by Editing It

The most straightforward and natural way to solve a conflict is by editing the affected files.
In this case, it's a matter of editing the merge Change zo:

@  l        empty
×  zm       My parent is conflicted
×  zo       Merge conflict           <- Resolve the conflict here
├─╮
│ ○  nz        merge-b
○ │  m         merge-a
├─╯
○  vr       Base of merge-a and merge-b
│
~

Notice: you've surely obtained a different Change ID. For convenience, let's call it nz+, meaning the nz's direct child.

Did I Tell You Not To Edit Changes?

If you are tempted to run jj edit zo, please, don't! Remember my heartfelt plea in Don't Edit. Do jj new zo instead. Remember that any change you perform in zo is automatically propagated. This way, you can review your resolution before finalizing it and easily undo any mistake.
So, do yourself a favor and create a Buffer Change:

jj new zo

This is what you get:

@  k        empty                    <- Your Buffer Change
│ ×  zm     My parent is conflicted
├─╯
×  zo       empty Merge conflict     <- The Change to fix
├─╮
│ ○  nz        merge-b
○ │  m         merge-a
├─╯
○  vr       Base of merge-a and merge-b
│
~

Of course, even this Buffer Change will be conflicted. That's exactly the point: you want to resolve the conflict from there, so it must inherit it.

So, here's the idiomatic workflow for attacking conflicts:

1. Run jj new targeting the conflicted Change.
2. When you've solved the conflict, jj squash, as per the mini-workflow.
3. If you want to start over, jj restore.

This is exactly the mini-workflow you saw in Don't Edit.

Resolving The Conflict

Edit the conflicted file file.txt. You will see this content:

Donec neque quam, dignissim in, mollis nec, sagittis eu, wisi.
Phasellus neque orci, porta a, aliquet quis, semper a, massa.
Etiam vel neque nec dui dignissim bibendum.
Nunc porta vulputate tellus.
Nunc eleifend leo vitae magna.
Sed id ligula quis est convallis tempor.
<<<<<<< conflict 1 of 1
%%%%%%% diff from: vrzponzu b12f7845 "Base of merge-a and merge-b"
\\\\\\\        to: mvxxwqoo e1acf668
-We will create a conflict here.
+We will create a conflict here: merge-a added this text.
+++++++ nzsunxwp 0004a47a
We will create a conflict here: merge-b added this text.
>>>>>>> conflict 1 of 1 ends
Nullam rutrum.
Curabitur vulputate vestibulum lorem.
Nullam eu ante vel est convallis dignissim.
Sed bibendum.
Aliquam posuere.

Let's learn how to read the conflict:

<<<<<<< conflict 1 of 1
%%%%%%% diff from: vrzponzu b12f7845 "Base of merge-a and merge-b"
\\\\\\\        to: mvxxwqoo e1acf668
-We will create a conflict here.
+We will create a conflict here: merge-a added this text.
+++++++ nzsunxwp 0004a47a
We will create a conflict here: merge-b added this text.
>>>>>>> conflict 1 of 1 ends

Interpreting Conflicts

The first and the last lines are obviously the conflict, with the total number of conflicts:

<<<<<<< conflict 1 of 1

>>>>>>> conflict 1 of 1 ends

All the lines above and below those boundaries are fine: both parents agree on them.
Between those 2 markers, you will find 2 elements:

1. How the 1st Change wanted to change the common Base.
2. The content of the 2nd Change.

Look:

%%%%%%% diff from: vrzponzu b12f7845 "Base of merge-a and merge-b"
\\\\\\\        to: mvxxwqoo e1acf668
-We will create a conflict here.
+We will create a conflict here: merge-a added this text.

Read it as:

%%%%%%% diff from: v "Base of merge-a and merge-b"       <- from the common Base
\\\\\\\        to: mvxxwqoo e1acf668                     <- the first Change merge-a
-We will create a conflict here.                         <- wants to apply this diff.
+We will create a conflict here: merge-a added this text.

Of course, - means deleting a line, + means replacing the line with some other content.

Resolving The Conflict

Here's a possible resolution:

Sed id ligula quis est convallis tempor.
We will create a conflict here: merge-a added this text, merge-b added this text.
Nullam rutrum.

*Very* interestingly, if you run jj st, you will see this message:

Hint: Conflict in parent commit has been resolved in working copy

Cool! That's how Jujutsu tells you:

Hey, pal! If you squash back this change, you fix the conflict.

Let's do that

jj squash

Perfect, it's all clear!
What about the Buffer Change? No worries, it's an empty, messageless Change. It will be automatically abandoned once you move away; it was a temporary working area from the start.

Conflict Resolutions Propagate

Look how beautiful:

@  l        empty
○  zm       My parent is conflicted
○  zo       Merge conflict
├─╮
│ ○  nz        merge-b
○ │  m         merge-a
├─╯
○  vr       Base of merge-a and merge-b
│
~

Not only is zo clear: the conflict resolution propagated to zm and to @ too.

How cool is that?

Resolutions All The Way Down

That's a general rule. If you build on top of a conflict:

×  j     <- also in conflict
×  i     <- also in conflict
×  h     <- also in conflict
×  g     <- also in conflict
×  f     <- also in conflict
×  e     <- also in conflict
×  d     <- conflict
○  c
○  b
○  a

The moment you fix the conflict somewhere, the resolution will be propagated. Say you fixed the conflict in f, you'd get:

○  j
○  i
○  h
○  g
○  f     <- resolved here
×  e     <- conflict
×  d     <- conflict
○  c
○  b
○  a

Of course, ideally you'd fix the conflict where it originated. In this case, since you already have a resolution in f you can jj squash it to d:

○  j
○  i
○  h
○  g
○  f
○  e
○  d
○  c
○  b
○  a

I hope you got the idea.
Ready to see some more challenging cases?

Using the GUI

Before proceeding: do you prefer using a GUI tool such as kdiff3?
No problem:

jj resolve --tool kdiff3

Git Style Conflict Markers

Jujutsu is not an opinionated tool. Do you prefer Git-style conflict markers?
Configure your repo with:

jj config set --repo ui.conflict-marker-style git

and, presto!, you are back to your familiar format.

Rebase Conflicts

I bet this chapter will be a mere formality for you. You already know how to resolve a rebase conflict. Don't you think? Challenge yourself. Move the feat-1 branch on top of vr:

○  so
○  o        Merge conflict
├─╮
│ ○  nz        merge-b
○ │  m         merge-a
├─╯
○  vr       Base of merge-a and merge-b base
│ ○  y        empty  feat-2
│ ○  vw       empty
│ ○  x        empty
│ ○  vn       empty
│ ○  r        Rebase vr:: here
├─╯
│ ○  no       empty  feat-1
│ ○  vt       empty
│ ○  sy       empty
│ ○  u        empty
│ ○  vz       empty
├─╯
○  q        empty  main
◆  z    🔒  empty

jj new feat-1

jj rebase -o vr

jj rebase -s vz -o vr

Here we go, a conflict in s:

@  no        feat-1
×  vt
×  s        Will conflict
○  u
○  vz
│ ○  y        empty  feat-2
│ ○  vw       empty
│ ○  x        empty
│ ○  vn       empty
├─╯
○  r        Rebase vr:: here
│
~

As you see, the conflict arises in s and is propagated to all descendants.
How to resolve it? Remember to use the jj new && (jj squash || jj restore) workflow you saw in Don't Edit.

jj new -r s

<<<<<<< conflict 1 of 1
+++++++ unmwmutn 91e9daba "" (rebase destination)
  // This comment will get a conflict
%%%%%%% diff from: unmwmutn e6f1eb22 "" (parents of rebased revision)
\\\\\\\        to: nolxxptq 09ad5fbc (rebased revision)
+  // Handle theme color and mode
>>>>>>> conflict 1 of 1 ends

  // Handle theme color and mode

jj squash

If you got it right, good job! You will see how the resolution propagate from s all the way down its descendants:

○  no        feat-1
○  vt
○  s        Will conflict
○  u
○  vz
│ ○  y        empty  feat-2
│ ○  vw       empty
│ ○  x        empty
│ ○  vn       empty
│ ○  r        Rebase vr:: here
├─╯
~

See? A walk in the park.

Multiple Rebase Conflicts

@  zq       empty
○  y          feat-2
○  unv
○  vw       Will conflict
○  xw
○  xl       Will conflict
│ ○  nz        merge-b
│ │ ○  m         merge-a
│ ├─╯
│ ○  vr       Base of merge-a and merge-b base
│ ○  r        Rebase here
│ ○  l        No idea why
├─╯
│ ○  no        feat-1
│ ○  vt
│ ○  s        Will conflict
│ ○  unm
│ ○  vz
├─╯
○  q         main
◆  zz   🔒  empty

Without further ado, rebase feat-2 on top of r:

jj rebase -s xl -o r

jj rebase -r xl:: -o r

@  zq       empty
×  y          feat-2
×  unv
×  vw       Will conflict
×  xw
×  xl       Will conflict
○  r        Rebase here
○  l        No idea why
│
~

Boom.

First Conflict

What's the conflict in xl?

jj show xl

    Will conflict

Created conflict in README.md:
    ...
   4    4: problem has finally been solved. This app lets you write things down
   5    5: and then cross them out. So cool.
   6    6:
   7    7: ## Features You Won't BeleiveBelieve
   8    8:
   9    9: - Adding tasks. You type words. They appear. Groundbreaking.
  10   10:
  11   11: - Completing tasks. Click a tiny box and watch your task get a line
  12   12:   through it, wich is basically like deleting it.
       13: <<<<<<< conflict 1 of 1
       14: %%%%%%% diff from: qmyyoorn bdcd7f2b (parents of rebased revision)
       15: \\\\\\\        to: roulqqom 67bb45ac "Rebase here" (rebase destination)
  13   16: +:quit
  14   17: +:qw
  15   18: +:wq
  16   19: +:q!
  17   20: +:x
  18   21: +:exit
  19   22: +:how to quit this editor?
  20   23: +:emacs
  21   24: +:emacs help
       25: +++++++ xlkttytw e08dfcc6 "Will conflict" (rebased revision)
       26:
       27: - Filters. All, Active, Completed. Choose your poison.
       28:
       29: - Inline editing. Made a typo? Double-click and fix it. So cool!
       30: >>>>>>> conflict 1 of 1 ends

jj new r
jj restore -f r- README.md
jj squash


@ r           empty
│ ×  y          feat-2
│ ×  unv
│ ×  vw       Will conflict: deleted file
│ ○  xw
│ ○  xl       Will conflict: Vim
├─╯
○  r        Rebase here
○  l        No idea why
│
~