[philwelch]

I do that in Git all the time. JJ might be easier in some sense but “more powerful” implies that it can do things that are impossible in Git.

[andrewaylett]

JJ has first-class support for conflicted trees, changesets, branches, and operations. The op log itself is a (really useful) feature not present in Git.

You can always end up with the same set of published commits, guaranteed. But the tools you have for manufacturing them and for interacting with their history definitely include things that are possible in JJ but not in Git.

[sunshowers]

If you're in the middle of a git rebase -i of a stack of 20 commits, and realize while editing commit 15 that you made a mistake at commit 8, how do you go back and edit commit 8 without having to complete the rebase -i?

This is not contrived — this is an entirely realistic scenario that I use jj to handle all the time.

[1718627440]

True nested rebase doesn't exist (yet) in Git. What I do is create another commit with the parent commit 8 with commit --fixup and then complete the rebase. The I can just autosquash it, without reediting anything.

You could also keep the rebased commits, abort the rebase, rebase the already rebased commits and then continue the first rebase.

[sunshowers]

With jj, because it doesn't have modal states of any kind, you can just go back to commit 8, edit it, and everything dependent on it gets auto-rebased. You can also do jj squash --into for a workflow similar to fixup commits.

I would consider the first workflow to be impossible to do by most mere mortals in Git [1]. Meanwhile in jj it's downright trivial.

[1] There technically is a way to do this by setting a temporary branch, aborting the rebase, starting another rebase -i, carefully editing the interactive instructions, going to commit 8, editing that commit, then cherry-picking 9-15 from the temporary branch. But it's too hard to do in practice, and far too easy to get wrong.

[1718627440]

> [1] There technically is a way to do this

That's what I've described?

> rebase -i, carefully editing the interactive instructions

You neither need to use interactive rebase nor carefully edit, since there is rebase --onto.

> But it's too hard to do in practice, and far too easy to get wrong.

I do this often it's not more complicated then any other rebase.

What is annoying in Git is rebaseing across multiple merges while forging committer and date information. Can JJ do that better?

[sunshowers]

Ah I misinterpreted what "keep the rebase commits" meant.

I'm glad you don't find it too difficult to do. It's a workflow that seemingly works well for you!

[Vinnl]

I think generally when people say that for jj, they mean it can do the same things with fewer concepts.

[sswatson]

The author lists that as a separate benefit, though.

My interpretation is that jj makes certain useful operations convenient to use that would be so complex in git as to be completely impractical. Something like jj undo would be a simple example: jj users can do it, and git users can’t, even though it’s logically possible in both systems.