Restore change to an earlier commit-state

[BatmanAoD]

This seems like it should be obvious, but I can't find documentation for it: with jj evolog, you can see the history of a change over time. Is it possible to use this information to set a change back to a prior commit state?

Just restoring the contents from the earlier commit doesn't preserve the metadata, so it will have a different commit ID.

This can be done with the operation log by reverting to a particular repository state or undoing a sequence of operations, but it seems like it should be simple to modify the change directly and restore a previous commit. Maybe jj abandon <change> followed by some way of un-hiding the commit by ID?

[scott2000]

The easiest way to unhide the old commit would probably be to do jj new <old_commit_id>. This would then create a divergent change (since two versions of the change are now visible), which you could resolve by abandoning the one you no longer want.

[BatmanAoD]

The "prior state" commit is still in the repo. So, in terms of the operations performed, the only way to restore it is what Scott suggested.

...or to selectively undo certain operations, as I mentioned above, which of course does preserve the change ID.

[ilyagr]

Re Scott: I'm not sure exactly.

At first glance, I think replace might be good. I don't like the idea of further overloading rebase for this. For one, jj rebase -r can take multiple revisions. For another, rebase is a bit misleading, since the command rebases descendants.

This is also related in my mind to a potential flag to jj duplicate that moves the bookmarks and descendants to the new commits. That could be jj duplicate --replace.

More vaguely, the end of the second paragraph above makes me wonder whether there's some insight into the naming/better UI for the restore-descendants flag that we could glean from this.

[ilyagr]

...or to selectively undo certain operations, as I mentioned above, which of course does preserve the change ID.

Oh, of course, that works too. I updated my earlier message.

[scott2000]

At first glance, I think replace might be good. I don't like the idea of further overloading rebase for this. For one, jj rebase -r can take multiple revisions. For another, rebase is a bit misleading, since the command rebases descendants.

Technically, it could probably be defined for multiple revisions still, like I think you could say jj rebase -r X --replace Y is equivalent to jj rebase -r X -A 'roots(Y)-' -B 'heads(Y)+' but with all commits in Y being abandoned. But probably that's really confusing so not a good idea.

[ilyagr]

I think it would make sense to define jj replace for linear sequences of commits if from/to. This is, of course, a special case of your suggestion; I'm not sure whether people would want that in non-linear cases, though.

Another possibility (but certainly not for the first version) would be to make it order dependent. We recently rejected something like this for jj push --changes --named, but if we really wanted to, we could allow jj replace --from A::C --to X::Z --from D --to W to map

A -> B -> C
   D --/

to

X -> Y -> Z
   W --/

[jpmhouston]

Just starting out with jj, I accidentally abandoned the initial 4 changes in my repo while fumbling with commands I meant for deleting a bookmark. I didn't catch it in time to do an undo and have been searching for how to un-abandon changes, and found my way to this thread.

I've now used jj evolog and was happy to find the changes I abandoned, and yes adding a new empty change to one makes its abandoned parent visible in the log again but only as long as I keep that empty change stays around. I now made bookmarks on branching empty changes to each of the 4 abandoned ones, but I'd rather not have to keep those branches around.

I see jj evolog shows me previous states of those changes, interesting, however I'm not trying to restore any of those, just want to un-abandon the latest state of each so they show again in my history. I'm not following what people are saying about jj rebase in this thread. I'm wary (more than I was when fumbling around earlier today) of trying any more seemingly drastic things I don't quite understand.

If there's no good way to un-abandon changes at the moment, I'm hoping something like this can be added to jj at some point. Thanks for listening to my tale of woe!

[PhilipMetzger]

you can use the operation log jj op log to search the operation before you abandoned your commits and then time-travel back to that snapshot with jj op restore <op-id>

[martinvonz]

but only as long as I keep that empty change stays around

They're not supposed to disappear after that either. Please file a bug report if that's actually what you're seeing. Or maybe you're just assuming that would happen based on how Git's detached HEAD state works?

[joyously]

I think what is unclear for new users is whether the commands are affecting the old state (and ripple forward in the graph) or the commands are applying the old state to the existing working copy only.
I don't think the docs make clear what happens with all the states in between the current and the one referenced in the command with <op-id>.

[jpmhouston]

I don’t think I had any confusion myself between what commands affected previous state vs. the working copy. I knew I wanted to change the history, but my problem was simply that I misread what “abandon” meant. In trying to remove unwanted bookmarks I ended up removing the changes themselves 🤦‍♂️

I don’t recall what the output of the abandon command was, only that I didn’t notice it and when I looked through my scrollback later I stil l think it was clear what happened. What would have helped was output from that command that prominently said something like “change xxxx abandoned, to restore use the command ‘blah’”, and of course there being a command ‘blah’ for it to recommend.

I can file a bug about the once-abandoned changes not staying un-abandoned, but I’ll first try to reproduce the issue in a test repo.