Possibility to get into an "undo loop" and recreate an uncontrolled mess

[rsmyth-ecmi]

Hello,
I have encountered this twice now. But basically if you run jj undo several times in a row, your repo can get extremely messed up very fast. I literally just did that and I now have 10 conflicts cannot undo my way out.

The reason why I do this is that I expect JJ to work like other "undo", where I can run "undo," check the state and if I need to go back further, just run "undo" again. I mainly do this when attempting to recover from a bad rebase I did.

Last time I used the autocompletion to find the best revision. This time I did not and now I just need to nuke the repo and reclone it as it seems to be messed-up beyond repair.

This UX is quite bad tbh, which is unfortunate as I think the undo feature is one of the best features of JJ.

[emilazy]

We now warn if jj undo undoes an undo operation. I’m surprised that it messed things up though, since it should just be swapping back and forth between two states. Do you have other things modifying the repository at the same time (e.g. Git auto‐fetch in an editor?)

It’s very unlikely your repo is broken beyond repair. If you look at jj op log, you can jj op restore to an operation before you started running the jj undos.

[PhilipMetzger]

For more info see #3700 and why the current behavior isn't ideal.

[rsmyth-ecmi]

I tried to go back using the op log but it just kept getting more messed up. The only thing I did was "jj undo" to various states.

[rsmyth-ecmi]

I already nuked it so I cannot inspect further

[emilazy]

You probably want jj op restore rather than jj op undo if you’re specifying a specific operation. The latter will undo just the changes from that operation rather than restoring to its state, which probably contributed to things getting messed up. jj op restore should still have been able to fix it, though.