cli: New --changes-in argument to jj restore

[ilyagr]

This argument can restore a merge commit to the merge of its parents. This allows one to apply the default behavior of jj restore to another commit. In other words, jj restore without arguments is equivalent to jj restore -c @.

Original description (before switching -r => --rp)

The title was "cmd: Add -r argument to `jj restore

The interface is now similar to jj diffedit, jj diff, etc.

Checklist

If applicable:

• I have updated CHANGELOG.md
• (not planned) I have updated the documentation (README.md, docs/, demos/)
• (n/a) I have updated the config schema (src/config-schema.json)
• I have added tests to cover my changes

[ilyagr]

I thought about this again since it's related to recovery and the message to be printed in #1679.

How about something like jj restore --revision-from-parents? Perhaps with a shorter alias like --rp. jj restore -r would print a hint and exit.

[ilyagr]

It took me a while to update all the docstrings, hope the result is clear enough.

[martinvonz]

restore is not interactive and does not use an external diff tool. It doesn't show the diff at all.

By the way, I've been confused by this a lot of times. In my mind, I want to copy some contents over from one revision to another, so I try jj restore --from X -i but that flag doesn't exist. We should probably roll back f6d226e. With the change in this PR, it seems like diffedit and restore have the same functionality except that one is interactive and one is non-interactive.

[ilyagr]

We should probably roll back f6d226e

jj rebase -i is confusing to me. On one hand, I'd expect it to default to restoring everything, which would mean having the "from" side on the right and the "to" side on the left. On the other hand, that seems confusing, especially if jj diffedit also exists with the "from" side on the left.

Some options that come to mind:

• Print a hint to use diffedit when the user does jj rebase -i.
• Ignore the problem I mentioned and explicitly say that jj rebase -i is a synonym for jj diffedit (except the --rp option is named weirdly different than -r, though I suppose we could accept -i -r if we really wanted to).

In any case, I think that's outside the scope of this PR.

[ilyagr]

BTW, to substitute for Github autolinking, @avamsi opened a related discussion at #1929.

[martinvonz]

We should probably roll back f6d226e

jj rebase -i is confusing to me. On one hand, I'd expect it to default to restoring everything, which would mean having the "from" side on the right and the "to" side on the left. On the other hand, that seems confusing, especially if jj diffedit also exists with the "from" side on the left.

Some options that come to mind:

• Print a hint to use diffedit when the user does jj rebase -i.
• Ignore the problem I mentioned and explicitly say that jj rebase -i is a synonym for jj diffedit (except the --rp option is named weirdly different than -r, though I suppose we could accept -i -r if we really wanted to).

I really like the idea of using a 3-pane diff we talked about in #1905 (comment). One of the advantages of that is we can have the initial state be either the left or the right side. For jj diffedit, we would presumably default to the right side, but for jj restore -i, we'd default to the left side. What do you think?

In any case, I think that's outside the scope of this PR.

Agreed.