More powerful jj split

[augustebaum]

Hi,

Not sure if this use-case is already covered by jj:

1. I work on change a for a while.
2. I go work on something else (or any operation that results in a new "evolution" for a in jj evolog).
3. I come back to work on a.
4. Some of my new work on a overwrites the previous work.
5. I'd like my new work on a to be split off a in a new change, while putting back a at the state it was after step 1.

Because step 4 modifies some lines that were already new changes, jj split wouldn't be sufficient.

I know that jj keeps track of how each change evolves (I can track this with jj evolog) but I don't know how to access that information to do productive things like the above with it.

Would appreciate any help! jj is awesome!

[scott2000]

Maybe #4097 would help with this? Currently there is also jj restore --from <old_commit> --to <new_commit> --restore-descendants which can be useful in some cases I think.

[augustebaum]

I admit I've never managed to get a clear understanding of jj restore; thanks for the pointer. Could I trouble you for a more detailed example?

As for the PR, yes, this sounds like exactly what I'm looking for :)

[scott2000]

Basically, commits can be treated as either snapshots (the contents of files at that commit) or diffs (a set of changes compared to the commit's parents). Usually, jj treats commits as diffs, so when you make a change to one commit, then jj will rebase all of its descendant commits on top of it, preserving their diffs.

jj restore conceptually works on snapshots, like it basically lets you set what the file contents should be. So jj restore --from <old_commit> --to <new_commit> would just reset the file contents back to the old commit's file contents. This has the effect of discarding all of your recent changes from the commit.

The --restore-descendants flag is a bit complicated. Instead of automatically rebasing all descendant commits and preserving their diffs, it rebases them but preserves their snapshots instead. This has the effect that the file contents of all descendant commits won't change. So, if you have an empty commit on top of <new_commit>, and you run jj restore --from <old_commit> --to <new_commit> --restore-descendants, then <new_commit> will be replaced with the contents from <old_commit>, and the originally-empty commit on top of <new_commit> will retain its file contents, causing it to no longer be empty (it will now contain all of the changes between <old_commit> and <new_commit>).

I think a full example would be:

# Find the old commit ID
jj evolog -r 'a'
# Create an empty commit on top of 'a'
jj new 'a'
# Restore changes from old snapshot of 'a', putting the recent changes into the empty commit
jj restore --from '<old_commit>' --to 'a' --restore-descendants