"I forgot to jj new and this went to the wrong change"

[gasche]

A somewhat common issue I have with jj for certain kind of documents (in particular text documents as opposed to code) is that I will forget to jj new or jj commit. Yesterday I worked on something self-contained and nice and I used jj describe to git a good change name. Today I come back and I start writing/hacking, and when I decide to commit I realize that all my changes went in yesterday's commit, and this is not what I wanted. I don't currently know of a convenient way to fix this issue after the fact, unless the changes are separate enough that jj split can do it.

My current approach is as follows:

• copy all the files I touched today inside /tmp
• use jj op log to find the last snapshot yesterday, and jj op restore to go there
• jj new to start a new change
• copy the modified files back from /tmp

Is there a simpler way to do this that I am missing? Some of the git reset options allow to do this -- but this relies on the distinction between the HEAD state and the working copy. I have not found a way to do this in jj, and I am not sure what would be a good interface.

One thing that would make sense to me would be jj split --after-operation <op>, which check that <op> had the same working-copy revision than we currently have, and move all working-copy updates after <op> in a new commit.

[tim-janik]

I don't currently know of a convenient way to fix this issue after the fact, unless the changes are separate enough that jj split can do it.

This is partly an FAQ:

• https://martinvonz.github.io/jj/latest/FAQ/#i-accidentally-changed-files-in-the-wrong-commit-how-do-i-move-the-recent-changes-into-another-commit

I run into that myself quite often, which is why I've added a simple way to jj-fzf to achieve this:

• Start jj-fzf in your repo: https://github.com/tim-janik/jj-fzf/
• Hit Ctrl-O for the op-log
• Select the operation that still contains the old (yesterday's) changes
• Hit Alt-W: Restore working copy of the selected operation into a new commit before @

This uses jj new -b @ && jj restore --from "$COMMIT" --to @ --restore-descendants under the hood, so you most recent changes are not affected.

[gasche]

Thanks! The FAQ entry indeed answers this question, and I somehow missed it. I spent some time wondering whether it would be possible to improve the --help output of various commands to make this more discoverable, but I am not sure how. (I tend to browse in-terminal help more than the web when using CLI tools.)

I find the way that the FAQ does it a bit convoluted. It suggests the following step:

1. jj evolog to find the two commits ids, say 123 (before the mistake) and 456 (after the mistake)
2. jj new to create a new commit
3. jj restore --from 123 --to @- to fix the previous-head commit to 123
4. jj restore --from 456 to restore the after-change state in the new commit

Personally I find it more natural to do it as follows (which also works today):

1. jj evolog to find the two commits ids, say 123 (before the mistake) and 456 (after the mistake)
2. jj restore --from 123 to revert to the before-change state
3. jj new to create a new commit
4. jj restore --from 456 to reset the after-change state in the new commit

But both are fine and I consider the case closed. (Maybe jj new --from 456 could be supported to do jj new; jj restore --from 456.)

[joyously]

Where in the --help would this make sense? (or should it just be a link to the FAQ?)

Perhaps the long restore command suggested could be an alias?

[arxanas]

Possibly the operation you logically want is rebase with "reparenting" (I think not implemented for any command yet, but I could be wrong). Then you would write something like

$ jj edit 456
$ jj rebase -r @ -d 123 --reparent

and it would rebase 456 to be a child of 123 by simply updating its parent commit, without doing a textual rebase. That way, any changes between 123 and 456 are reflected in the diff between them, but we operated only on snapshots to do so. It's similar to git reset in some ways.

[gasche]

@arxanas Note that 123 and 456 are commit ids, not change ids, and in fact they both correspond to different evolutions of the same change. The workflow described above create two separate changes (the second one is created with jj new) and then reset them to those specific commits. The workflow that you describe does not give the same information: after jj edit 456 I expect to still be working on the same change, and then jj rebase -r @ -d 123 --reparent would ask to rebase a revision on top of itself, and I am not sure how jj would be supposed to know what to do in this case.

[arxanas]

@gasche I'm not sure why the workflow I'm proposing would result in a problem? I think I correctly understood that they're different commit IDs for the same change over time. Since they're commit IDs, jj should have no problem rebasing one on top of the other. If you were referencing them both by change ID, then I could see how jj might get confused about which one you're trying to address.

I can see now in my workflow that it might result in change divergence since both commits would have the same change ID. Is that what you meant? jj shouldn't prevent the operation from happening, as far as I know, but it would be inconvenient to resolve as we don't have a way to reset/assign a new change ID to an existing commit. (In this case, we could potentially use jj duplicate instead, to associate a new change ID, if it were to also gain a "reparenting" flag.)

[gasche]

Yes, my worry is that this interaction sequence tries to put the same change twice in the same history, and that sounds like something that is under-specified (create a new change, for which of the two? what description to use for the new change?). In contrast the interaction using jj new has the user in control of creating the new change.