"split" a commit using a previous version of that commit?

[BatmanAoD]

Here's a situation I've run into a few times:

• @ is the tagged commit on a branch.
• The branch is pushed to a remote.
• I make some changes, then decide that these actually should not be squashed into the current branch-tip; instead, I want to create a new commit with the new changes.

It's trivial to get the changes that belong in the new commit with jj diff --from <branch>@<upstream>. But is there a good way to generate the commit itself?

I've tried jj rebase -d <branch>@<upstream>, but I get an error message about an immutable commit. I previously tried using duplicate and then rebase, but... ah... I've forgotten whether that actually worked or not. 😅

Is there a better approach? (A generic way to generate a commit from a diff, perhaps as an option on diff itself, would be kind of cool. I think git can do this with a clever use of git-apply, though I haven't actually tried it.)

[martinvonz]

There's an entry in the FAQ about this.

(A generic way to generate a commit from a diff, perhaps as an option on diff itself, would be kind of cool. I think git can do this with a clever use of git-apply, though I haven't actually tried it.)

Makes sense. jj move moves a diff from one commit to another. We could have something similar for applying the diff between two arbitrary commits into another commit, if this turns out be a common enough request.

[necauqua]

@ is the tagged commit on a branch.

Immediate red flag (lol) - I treat @ as more of an ephemeral thing, it should rarely be tagged/branched/pushed - basically there are two workflows, using jj edit for checking out stuff and using jj new for that - and the latter is better imo, you don't touch that named real parent commit unless you explicitly want to - which is easy, just jj squash/amend if you need to actually amend it.

And all the benefits of index being a commit and not needing stashes etc etc remain

[BatmanAoD]

Yes, I agree. I've been trying edit to avoid littering my tree with empty commits, but that's not really a good trade-off.

[necauqua]

Actually about that whole discussion - I never have "ephemeral" commits (ones that are empty & undescribed & have no children) lingering around - whenever I change the @ (by jj new/commit usually) those get dropped, so the jj new workflow works great - not sure how that happened to you