Can someone help explain what 'jj prev' is for?

[chummer80]

I'm new to using jj, so please bear with me as I ask an ignorant question:

The combination of the name of the prev command, the docs, and the actual behavior I see in v0.28.2 make me feel like I don't understand the purpose of this command.

The most intuitive thing something called jj prev could do would be to simply change @ to its parent. But it does not. That's what jj prev --edit does (which is seemingly the same as jj edit @-).

So what's jj prev do? I tried to figure it out starting with a very simple linear revision tree, with @ at the tip of it.

@  xtzzymxs 2025-04-13 11:23:28 1d8b69e4
│  foolish mortal
○  symprlmu 2025-04-13 00:10:46 b9e41722
│  OK now
○  mqznwsuo 2025-04-12 21:13:28 072eab45
│  it's important to comment code
○  skyxoutn 2025-04-12 20:20:17 533f81a1
│  create sveltekit demo app using sv CLI
◆  zzzzzzzz root() 00000000

Running jj prev results in this:

@  lzrukmsp 2025-04-13 14:17:12 2fe2549b
│  (empty) (no description set)
│ ○  xtzzymxs 2025-04-13 11:23:28 1d8b69e4
│ │  foolish mortal
│ ○  symprlmu 2025-04-13 00:10:46 b9e41722
├─╯  OK now
○  mqznwsuo 2025-04-12 21:13:28 072eab45
│  it's important to comment code
○  skyxoutn 2025-04-12 20:20:17 533f81a1
│  create sveltekit demo app using sv CLI
◆  zzzzzzzz root() 00000000

Despite the name prev, it doesn't seem like it has done anything with @'s parent revision. Instead, it's made a new revision based on @'s grandparent, and has started editing that new one. In other words: it creates a pibling of the current @, then jj edits it.

Is this what jj prev is intended to do? Do people want to do this so often that there's an entire command for it? I must be missing something. (Or perhaps this is just a bug in v0.28.2. )

If I'm misunderstanding what jj prev does and why someone might use it, I hope someone can explain it to me. Thank you!

Side note: I believe jj prev --edit behavior is so different from jj prev that those 2 should be separated instead of using the same name.

[andyg0808]

So: for the way it looks like you're using JJ, jj prev --edit will be the one which makes sense. Here's why jj prev's behavior also makes sense, and is related.

There are two main schools of thought in using JJ:

One is the folks who typically use jj edit to work on a commit, and the changes they make apply immediately to that commit. It's not uncommon to see them with @ pointing at a commit with a description and code. For these folks, jj prev --edit makes sense, and jj prev seems weird.

The other is the folks who use jj new in the way one might use git checkout, and who squash work into a commit in order to change it. Their resting state is typically to have @ on an empty commit with no description. For these folks, jj prev makes sense. Here's why:

Looking back at the example you gave, imagine that lzr (described as "foolish mortal") was empty. The visible contents of the repo would be those of its parent, sym ("OK now"). Calling jj prev at this point results in @ being at a new child of mqz, which means that the visible contents of the repo are those of mqz, the previous commit from sym. Thus, jj prev.

This is confusing in the situation you're in, because the original @ commit (xtz) wasn't empty & undescribed, and so wasn't discarded when @ moved. If you call jj prev again, you'll see that it only moves one commit "back" at a time. If xtz had been empty, the graph after your call to jj prev would have looked like

@  lzrukmsp 2025-04-13 14:17:12 2fe2549b
│  (empty) (no description set)
│ ○  symprlmu 2025-04-13 00:10:46 b9e41722
├─╯  OK now
○  mqznwsuo 2025-04-12 21:13:28 072eab45
│  it's important to comment code
○  skyxoutn 2025-04-12 20:20:17 533f81a1
│  create sveltekit demo app using sv CLI
◆  zzzzzzzz root() 00000000

which hopefully looks more like it's the "previous" commit now. (JJ automatically discards the empty & undescribed commit that @ is at when moving.)

If you want more information about the two JJ workflows I've mentioned above, see Steve Klabnik's tutorial.

[jennings]

jj prev does something that has seemingly nothing to do with the previous commit.

In your original post, using jj prev while editing xtz is asserting to jj:

• sym is logically the commit I’m working on.
• xtz is my work in progress that I plan to squash into sym.
• The parent of sym, mqz, is the “previous” commit.

jj prev only makes sense if you use the “squash workflow”, where @- is logically the commit you’re working on. But, jj doesn’t know that you’re using the squash workflow. It doesn’t know what xtz is intended to be, so it can’t really block using jj prev in this situation.

[chummer80]

Thank you! It makes so much more sense after realizing @ is not the "current" commit, @- is. Which means @-- is the "previous" one.

And I'm also now realizing why it creates and edits a new empty commit based on the one that's considered "previous", rather than just editing "previous". It's because the assumption is that if you're using jj prev, you're using the squash workflow. You're supposed to use the empty commit as staging area for changes you plan to squash into "previous". And that's what you meant when you said "work on" a commit.

[joyously]

Thank you! It makes so much more sense after realizing @ is not the "current" commit, @- is.

Too bad the newcomers (and even some of us that have been around awhile) can't quite get this, even after reading all of these comments. I guess I don't have any of those assumptions.
I would do jj new xyz if I want to do new work on that line of development; not thinking of squashing it anywhere.

[jennings]

Too bad the newcomers (and even some of us that have been around awhile) can't quite get this, even after reading all of these comments.

That's totally okay! I've been using jj for almost 2 years now and I've used the "edit workflow" almost exclusively. It just means that jj prev isn't as useful to me, which is why I have an alias jj p which does jj prev --edit.

[cenviity]

And I'm also now realizing why it creates and edits a new empty commit based on the one that's considered "previous", rather than just editing "previous". It's because the assumption is that if you're using jj prev, you're using the squash workflow. You're supposed to use the empty commit as staging area for changes you plan to squash into "previous". And that's what you meant when you said "work on" a commit.

@chummer80 If you use the 'edit-based' workflow exclusively and want to default to using the --edit flag with jj prev / jj next, you can make use of the ui.movement.edit config: https://jj-vcs.github.io/jj/latest/config/#behavior-of-prev-and-next-commands