Re: Semantics for one step undo/redo

JS> I think my approach differs a little from Junio's (but I haven't JS> analysed his deeply) in that the redolog is actually just the slightly JS> edited output of git-rev-list --merge-order --parents head base [ the JS> edits removes from the list the parallel branches that aren't actually JS> involved in the undo ]

JS> Comments?

I've only took a brief glance at your description and found it quite sensible. I did not find anything majorly wrong.

If you are talking about jit-rewind (I think the message I told you about it was not sent to the list, so the list audience may not know about it, by the way), there is not much to analyze.

It populates the snapshot pool with the commits in the specified commit chain, and after that it is totally up to the user what to do with them, hence there is no redo semantics attached to it. JIT way of doing things is generally more dangerous in that it gives you so much more flexibility that it lets you freely shoot yourself in the foot ;-). When the core Plumbing side stabilizes I may revisit updating JIT to make certain parts of it not so sharp-edged, but I have been busy futzing with the Plumbing side lately, and having found not much need to change JIT, haven't done much about updating my own Porcelain.