Replies: 3 comments 10 replies
-
This is quite the same as the state after an empty
It means that the operation that imported |
Beta Was this translation helpful? Give feedback.
-
|
thanks. as said, I'm new to jj and not "on personal terms" with git, but I understand, roughly. still:
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 |
Beta Was this translation helpful? Give feedback.
-
|
well, it was easy enough to get there... I experimented a bit more. bottom line:
so this is perfectly fine. however, doing the same sequence in presence of pre-existing cloned git repo: so this is not perfectly fine IMHO: the 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 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 in the more relevant situation with pre-existing git clone to be imported upon |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
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.
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):
At this point, querying the repo with
gityieldsquestion: 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 redodid 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)
Beta Was this translation helpful? Give feedback.
All reactions