"infinite" jj undo does not restore initial state

[jghub]

very new to jj and not at all a regular, experienced git user (only where I can't avoid it), so I do hope the question is not too dumb. what I did:

• clone remote git repo where I do have push permission to main@origin
• jj git init
• jj bookmark track main@origin
  at this point jj log shows the most recent checkin as immutable (the solid lozenge marker in the DAG) and the empty, mutable @ revision on top. all good.
• lots of "jj ci" actions which leads to lots of mutable revisions in the DAG on top of the immutable one. as expected.
• some experimental jumping around to different revisions, some editing to see what happens etc.
• lots of jj undo in order to go back to initial state (to see whether "infinite undo" works...)

my expectation was, to finally hit "nothing more to undo" or "can't undo immutable revision" or something like that. what I actually encountered (as per jj op log output):

jj undo
jj undo
...
[~/rfiles/Rlibrary-git]$ jj undo              
   Restored to operation: b0b8aa18d593 (2025-11-14 00:31:35) import git head                                 
   Working copy  (@) now at: xqoyynrx 570c5363 (empty) (no description set)                                  
   Parent commit (@-)      : ylwyptkt b59ab853 main main@origin | wip.
   Added 0 files, modified 19 files, removed 2 files 
          ### the @-  commit is the immutable state of the initially cloned git repo.   
[~/rfiles/Rlibrary-git]$ jj undo              
   Restored to operation: 18a2729aea86 (2025-11-14 00:31:34) import git refs                                 
   Working copy  (@) now at: snvzkmyp a8f38e19 (empty) (no description set)                                  
   Parent commit (@-)      : zzzzzzzz 00000000 (empty) (no description set)                                  
   Added 0 files, modified 0 files, removed 516 files   
[~/rfiles/Rlibrary-git]$ jj undo              
   Restored to operation: f46e48e4cc55 (2025-11-14 00:31:34) add workspace 'default'                         
   Warning: Failed to resolve `revset-aliases.trunk()`: Revision `main@origin` doesn't exist  
[~/rfiles/Rlibrary-git]$ jj redo              
   Warning: Failed to resolve `revset-aliases.trunk()`: Revision `main@origin` doesn't exist                 
   Hint: Use `jj config edit --repo` to adjust the `trunk()` alias.                          

At this point, querying the repo with git yields

git log -> fatal: your current branch 'refs/jj/root' does not have any commits yet  
git checkout main -> error: pathspec 'main' did not match any file(s) known to git
git checkout -> fatal: You are on a branch yet to be born

question: did I do something that is not supposed to work (i.e. the attempt to undo beyond the point where this is known to not be possible (the immutable initial state)? also jj redo did not work any more at that point. so question 2: could such a seemingly corrupted state be restored to sanity with standard commands?

(this was with jj 0.35.0 on MacOS)

[yuja]

git log -> fatal: your current branch 'refs/jj/root' does not have any commits yet

This is quite the same as the state after an empty jj git init. There's no branch (in a Git sense) to show.

Warning: Failed to resolve revset-aliases.trunk(): Revision main@origin doesn't exist

It means that the operation that imported main@origin from Git has been undone, but the trunk() still points to main@origin in .jj/repo/config.toml. Since it is a warning message, jj undo would succeeded.

[jghub]

thanks. as said, I'm new to jj and not "on personal terms" with git, but I understand, roughly. still:

• the undo "chain" then goes beyond the first "jj init" which colocated the two repos. I understand that stuff is going on under the hood at that point and now in view of your answer presume, that the "undos" at that point undo those "invisible interactions" and leaves the repos in the encountered state.
• I do have nothing in the config.toml file refering to trunk() or main@origin
• whatever the undone actions are: why, then, is jj redo not able to reverting them?
• what would be the way to restore the repos to a usable state in terms of jj(and/or git) commands to issue?

of course I guess it is a one-of problem anyway since usually one would not do that (undoing everything ever done...). still, from a principal point of view (and first experience by newcomers etc.) it would be nicer if one could not as easily mess up: from naive user perceptive the initial jj init is the first action taken and it would seem natural if jj undo would refuse to undo that one, or, if it does, that it then removes the .jj repo and restores state of .git as it was at the time of jj init. I think preferable behaviour would be just to refuse undoing the initial jj init.

[yuja]

• I do have nothing in the config.toml file refering to trunk() or main@origin

It would be created by jj git init.

• whatever the undone actions are: why, then, is jj redo not able to reverting them?

No idea. What does the error message say?

• what would be the way to restore the repos to a usable state in terms of jj(and/or git) commands to issue?

You can use jj op log and jj op restore <operation-id> to roll back to a certain state. I think there would be "import git head" or "import git refs" operation at very end of the operation log.

[joyously]

it would be nicer if one could not as easily mess up

"easily"? You went through a lot of effort to get to this state, and it doesn't even look messed up, to me. Your redo didn't error, so it probably redid add workspace 'default', and it would take a lot of redo commands to get back to where you started (the multiple operations for each command is what is invisible to the novice user).

I think preferable behaviour would be just to refuse undoing the initial jj init.

I disagree, since commands can be multiple operations. I think if you undo all the operations of jj git init, there should be no trace of having done it, which means you can't redo it except by entering the init command again.

[jennings]

I think if you undo all the operations of jj git init, there should be no trace of having done it, which means you can't redo it except by entering the init command again.

I see the logic, but I think most undo stacks don't work this way. If you create a new word processor document, type, then press undo repeatedly, the button disables when you undo the earliest change rather than destroying the document window.

I think most people would expect repeated undo to stop instead of undoing the original jj git clone or jj git init. If that's what you wanted, you probably wouldn't use undo, you'd just rm -rf the whole directory.

[jghub]

yes, that was basically my point: I would have expected that I got "Nothing to undo" when trying to undo jj git init. the more so as repo is somewhat messed up after crossing that point and jj redo is no longer working.

[jghub]

well, it was easy enough to get there... I experimented a bit more. bottom line:

• a prestine, empty jj repo (no pre-existing git clone/repo involved) does behave nicely

jj git init # →Initialized repo in "."
jj undo # →Restored to operation: 000000000000 root()
jj undo # → Error: Cannot undo root operation
jj redo # → Restored to operation: 741ada87fbb7 (2025-11-23 16:51:09) add workspace 'default'
jj redo # → Error: Nothing to redo

so this is perfectly fine. however, doing the same sequence in presence of pre-existing cloned git repo:

jj git init # →Done importing changes from the underlying Git repo. Setting the revset alias `trunk()` to `main@origin` ...
jj undo # → Restored to operation: 540db4465ddd (2025-11-23 17:03:53) import git refs
jj undo # → Restored to operation: b0a49a99f01b (2025-11-23 17:03:53) add workspace 'default'. Warning: Failed to resolve `revset-aliases.trunk()`: Revision `main@origin` doesn't exist 
jj redo # → Warning: Failed to resolve `revset-aliases.trunk()`: Revision `main@origin` doesn't exist... Done importing changes from the underlying Git repo. Error: Nothing to redo

so this is not perfectly fine IMHO: the redo erroring out.

the bottom line behaviour-wise (for poor new user): if you undo until you get a warning, it's already too late to simply go back with jj redo. I so far tried futilely to somehow revert to a sane state with jj op restore and jj config edit --repo attempts but so far to no avail.

if someone has a recipe how to get cleanly get back from state after 2nd undo to state after 1st undo this would be interesting.

I emphasize again, that I do not claim that the present behaviour is technically a bug (no idea, whether it is that...). but I maintain, that the behaviour is not desirable (at least I cannot see any reason wanting to go back to before "import git refs"). compared to first example with prestine empty (.git) repo created by jj itself) where one can undo until error: cannot undo root operation and then can do redo.

in the more relevant situation with pre-existing git clone to be imported upon jj git init this simply is not the case. if it can't for technical reasons, so be it. but would it not be a good thing (at least by default) to detect when jj git init is reached and to refuse to undo that? i.e. stop before point of (apparent?) no return is reached by one undo too much...

[jghub]

yes, fully agree in both respects: not very impactful but potentially seriously off-putting to newcomers like me (I for one was at least sort of "disappointed" ;)).

[yuja]

jj redo # → Warning: Failed to resolve revset-aliases.trunk(): Revision main@origin doesn't exist... Done importing changes from the underlying Git repo. Error: Nothing to redo

So this "importing changes from the underlying Git repo" would prevent redoing further. iirc, there was an issue about skipping automated snapshots when doing jj undo/redo. If that's implemented, jj redo would bring you back to the original state.

[jghub]

this (restoring "redo" capability at that point) would of course be better. but I still wonder if it not would be preferable to catch the "trying to undo jj git init" corner case and to simply refuse doing that (thus preventing the repo getting in an unusable/strange state in the first place)?

[yuja]

if it not would be preferable to catch the "trying to undo jj git init" corner case and to simply refuse doing that (thus preventing the repo getting in an unusable/strange state in the first place)?

Since jj undo/redo are high-level commands, I'm not against adding special case like that. I don't feel strongly whether we should handle this edge case, though. It's very unusual to do jj undo way back to the initial operation.

[jghub]

I neither feel strongly about it. but as @jennings pointed out, it might help to not scare newcomers straight away ("uh it broke my repo just like that?! I will stop considering it any further ..."). UI-wise I think it just would be good, if it were handled (presuming it is easy to do), even if it sure is an edge case.