FR: partial/interactive `jj restore`, like `git checkout -p`

[jyn514]

Is your feature request related to a problem? Please describe. i have made a bunch of changes to cli/src/cli_util.rs. i've realized that about half of them won't work, and want to undo them with jj restore. but jj restore only allows me to edit entire files.

Describe the solution you'd like add a restore --interactive flag which allows me to chose which parts of the file are replaced, like jj squash --interactive.

Describe alternatives you've considered

• copy-paste from jj cat cli_util.rs
• create a new commit and jj move -i from the parent one bit at a time, then create another new commit on top of the parent and abandon the temporary working copy. that works but the UI isn't great. it reminds me of git in that i'm doing commands that end up with the result i want rather than just directly saying what i want.

Additional context jj 0.13.0-81b0e3bf3bf6f230740e93532b9a9767e8a4ef6e

[ilyagr]

This is what jj diffedit does.

Previously, we had both jj restore -i and jj diffedit, doing the same thing. I removed the former and mentioned jj diffedit in jj restore -i, but it seems people still have trouble finding it.

Perhaps we could have jj restore -i either just print an error, or print an error and call jj diffedit.

[martinvonz]

Perhaps we could have jj restore -i either just print an error, or print an error and call jj diffedit.

Or just make it work? There doesn't seem to be much harm in having two commands for the same thing, if that helps with discoverability. Actually, jj restore -i would perhaps show the diff to apply, which is the reverse of diffedit, so it seems useful for that reason too.

[ilyagr]

jj restore -i would perhaps show the diff to apply, which is the reverse of diffedit, so it seems useful for that reason too.

You mean that jj restore -i (or -ic, but without --from/--to) should make the left side of the diff editable or swap the sides? We could do that, I'm not sure whether that would be helpful or confusing.

For one, then just quitting the diff editor would (I guess) result in restoring everything, which is different from what all other commands do. OTOH, if we make this change, a version of split where you specify a diff for the child commit would make sense. That would also work with #2665.

For --from and --to, restore and diffedit seem identical.

Or just make it work? There doesn't seem to be much harm in having two commands for the same thing, if that helps with discoverability.

I don't know, this seems slightly distasteful, but perhaps documenting that these are the same in enough. Alternatively, we could make jj diffedit --from/--to print a warning, similarly to what jj checkout does now.

[martinvonz]

You mean that jj restore -i (or -ic, but without --from/--to) should make the left side of the diff editable or swap the sides?

Let's say my working-copy commit has some changes that kind of work but I want to start with a mostly new approach. I might then do jj new @- to start fresh. Then I want to copy over some of the hunks from the old attempt. My intuition is to think jj restore -i --from <previous attempt> and for that to show me my current state on the left and the previous attempt on the right. Since that command doesn't exist, I use jj diffedit --from <previous attempt> instead, but that will show the previous attempt on the left instead. To get some hunks from the previous into the new attempt, I have to select the opposite. I find that confusing. It's even worse when you need to edit some hunks (you can't, right?).

[ilyagr]

I see. This is possible with meld-3. We could in principle teach scm-diff-editor to accept three dirs and have a way to switch which side the diff is shown relative to. In the ideal world where this kind of UI is available to anyone, I'd prefer to keep the sides the same, to reduce confusion. In the current world, I'm not sure.

I've been idly wondering whether we could build some basic HTTP-based 3-pane-diff editor with https://codemirror.net/5/demo/merge.html. CodeMirror 6 has https://github.com/codemirror/merge, but that doesn't support 3-pane diff. (Actually, this should be a separate FR).

[jyn514]

Actually, jj restore -i would perhaps show the diff to apply, which is the reverse of diffedit, so it seems useful for that reason too.

i agree i would find that helpful. i think i've heard @eddyb mention in the past that they find checkout -p very confusing (i don't know if it's the equivalent of diffedit or restore -i), they may have opinions as well.

to be honest, i find the TUI for diffedit very confusing, i don't know whether this checkmark means "the change will be kept in the revision" or "the change will be removed from the revision"

[jyn514]

oh apparently it means only the changes you've checked are kept in the revision yeah i'm not a fan of that interface, what if it's a change that touches many different files? i only want to edit the changes i'm removing (for diffedit) or applying (for revise -i).

perhaps all the sections could be checked by default?

[arxanas]

@jyn514 There is a keyboard shortcut to toggle all checkboxes, so you can just start the session by pressing that. You could find out that this keyboard shortcut exists by clicking the Edit menu (with your mouse 🤮), which has two variations (a/A). We could certainly change the default toggled setting, but we'd have to confirm that it's desirable and also make sure that the behavior for non-builtin UIs also makes sense.

(You would be just one of many people to completely miss the keyboard shortcuts (see https://github.com/martinvonz/jj/discussions/2951). I filed https://github.com/arxanas/scm-record/issues/25 to track it.)