jj restore --from / --to options

[avamsi]

jj move for example, has pretty obvious --from / --to options but I can't seem to build a similar intuition for restore (or even diffedit and instead always need to check the help page beforehand).

I think part of the confusion comes from being able to read --from / --to either way -- i.e., "restore these paths from the way they're in $revision" or "restore these paths to the way they're in $revision" (if anything, the --to version sounds more natural to me and if there's a difference between these two, it's not obvious to me as a non-native English speaker).

Also, editing the --to revision (which is the current behavior) doesn't seem very natural to me (it's called --to in move because you're moving changes to it, with restore, something like -r seems like a better fit).

tl;dr: thoughts on jj restore [-r=@] [--to=r-] (current --to renamed to -r, current --from renamed to --to and --to allowing revsets)? Slightly related: #1298.

[martinvonz]

I think -r is much less clearly a source or destination than --from. Would jj restore --from X --into Y be clear?

[ilyagr]

How about using --source/--destination instead? One advantage of that is that we the short options make sense (we already use them in rebase).

That sounds fine to me. The parallel with rebase is actually a little problematic for me, since these options mean something different there, but I don't think it's a serious problem.

we have also talked about using -c when we do something with a revision compared to its parents

That's an interesting idea, I don't remember having discussed it myself. I like it, I think, especially for diff and diffedit.

I'm not 100% sure this would solve the restore issue entirely, but it might. To make it clear enough that people will not use jj restore -c when they mean --from, we could make the long version of -c to be --changes-in rather than just --change. I think "restoring the changes in REVISION" is OK English, though it bothers me a little bit that this phrase seems to match the functionality jj revert at least as well as what it's intended to mean.

[avamsi]

What would the final signature of restore be with -c/--changes-in? jj restore [-c=@] [--from=c-]? Or would there still be a --to? This change from -r to -c might apply to backout, diffedit, split, squash (and unsquash) as well?

I think I like -c better than --source / --destination, but remembering / guessing which commands take -c vs -r might be somewhat of an issue (will try this when using jj commands to see if my first guess holds up). Also, I would think some (Google internal) commands would want to use -c as CL(s), is that overlap not a concern?

[avamsi]

I was just going through #1298 (comment) and it's funny how it's almost exactly the same discussion 😅 (@yuja seems to like jj reset [-r=@] [--from=r-], @martinvonz already enumerated a bunch of commands for -r to -c) -- I actually like overwrite from that discussion, it doesn't come with any user expectations that -r would probably be okay to use but OTOH, it's "unnecessarily" diverges from restore / revert terminology.

[ilyagr]

I think I like -c better than --source / --destination

I think -c would go together with either --to/--from or --source/--destination, so it wouldn't help in the way you wanted.

I suppose it might also address @martinvonz 's concern: jj restore --changes-in REV seems to only have one possible meaning. So, maybe having just --changes-in and --from (with --changes-in acting like --to when --from is specified) is still an option. WDYT?

I'd be OK with it assuming that users would remember that -c means "changes in" rather than "change". I'm not certain about that.

I actually like overwrite from that discussion

Overwrite might be a decent name if we go with --changes-in and --from being the only arguments. With --to or --destination, it sounds awkward.

I was just going through #1298 (comment) and it's funny how it's almost exactly the same discussion 😅

Yes, I guess I forgot much of it by now; I should have reread it. But hey, I rediscovered --changes-in :). Also, one advantage of forgetting (in a glass half-full way) is that it's then easier for your understanding to change over time. Not that it seemed to change very much in this case.

remembering / guessing which commands take -c vs -r might be somewhat of an issue

Yes, I'm more worried about this after rereading the old discussion. squash seems like an edge case, for example: I could think of squash as either operating on revisions or on changes in a revision.

It could still work for restore specifically, instead of --revisions-from-parents, if we like.

[avamsi]

I agree with pretty much everything you've said, although I think I'm more in favor of dropping --to. And yeah, I like overwrite specifically in the context of using it with -r / -c (and --from) -- "overwrite this revision from this other revision" reads okay, I think.