[hdjrudni]

> If I had s -> t -> u -> v and wanted to reorder them, it’s as easy as jj rebase --revision u --after s, and I’d end up with s -> u -> t -> v,

How did t end up after u?

I'd expect that to fork into (s -> t) and (s -> u -> v). Either that or maybe (s -> t -> v) and (s -> u).

[martinvonz]

I'm not sure if you meant "how" or "why". As for "how", it's done by rebasing 'u' onto 's' and then rebasing 't' and 'v' onto the rebased 'u'.

As for "why", I think it behaves different from what you expected in two ways. The first is that `--revision` rebased only the specified revisions without theirs descendants (there's also `--source` if you want to include the descendants). The other things it that `--after` is a short form of `--insert-after`, so it's designed for inserting commits between other commits. There's also `--before/--insert-before`. There's also `--destination` which is what you expected (perhaps `--onto` would have been a better name for it). You can pass multiple commits to all these arguments, btw (yes, that includes `--destination`, so you can create new merge commits with `jj rebase`). https://jj-vcs.github.io/jj/latest/cli-reference/#jj-rebase has many examples.

[hdjrudni]

> it's done by rebasing 'u' onto 's' and then rebasing 't' and 'v' onto the rebased 'u'.

That sounds like 2 operations, not 1. I think that's why I was confused.

The docs do clarify that there's an extra rebase going on though, so thanks!

Yes, -d sounds like what I expected.