Re: Semantics for one step undo/redo

[Junio C Hamano <junkio@cox.net>]

>>>>> "JS" == Jon Seymour <jon.seymour@gmail.com> writes:

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.