Making rollback safer

[Matt Mackall]

On Tue, 2011-09-20 at 20:21 -0400, Greg Ward wrote:
> On Tue, Sep 13, 2011 at 5:51 PM, Matt Mackall <mpm at selenic.com> wrote:
> > Second, rolling back the dirstate should be seen as a side-effect of
> > truncating history: we don't want the dirstate to keep pointing at
> > truncated history. So if dirstate points at a revision that's not being
> > truncated, no action should be taken. Example:
> >
> > hg co stable
> > echo foo > bar
> > hg ci -Am "add new file bar"
> > hg co default
> > hg rollback -> should remove tip commit without jumping to stable
> 
> Done, as you no doubt noticed ("if parentgone" patch, 7c26ce9edbd2).
> 
> > Similarly, we shouldn't mess with rolling back the dirstate (or even
> > storing it!) if the last transaction had nothing to do with the
> > dirstate. Example:
> >
> > hg pull
> > hg add foo
> > hg rollback -> shouldn't unadd foo
> 
> This is tricky because the user might update after pull.

Well, no, that's a distinct use case and it's ok to get my case right
(done, thanks) without making any progress on your case:

hg pull
hg add foo
hg up
hg rollback -> we forget about foo

..which is the same as:

hg pull
hg up
hg add foo
hg rollback -> we forget about foo

Whatever the right answer is here, these two case should be the same,
which demonstrates that hacking in some sort of accounting on update
isn't sufficient.

But let's think about a simpler case:

hg commit
hg add foo
hg rollback -> we forget about foo, but get back any precommit adds

Without the add, we quite intentionally lose all the dirstate changes
that were present so that we can restore our old queued changes. I don't
know that we want to change this behavior, because people have the
expectation that they can do hg rollback; hg commit here. So within the
realm of the stupid semantics of rollback, I don't think we can/should
actually do much better here.

-- 
Mathematics is the supreme nostalgia of our time.