Mercurial undo command

[Sébastien Pierre]

Le 06-05-10 à 12:35, Bryan O'Sullivan a écrit :

> On Wed, 2006-05-10 at 12:23 -0400, Sébastien Pierre wrote:
>
>> I know that it may be complicated to implement, but simply consider
>> this question : wouldn't it be nice to be able to undo whatever
>> change you did to the repository or working directory ?
>
> I don't think so.  We already let you undo operations on the  
> repository,
> and that's fairly safe, because we control the repository.  But the
> working directory is completely under the user's control, and can be
> arbitrarily messed up by a user's actions.  In general, we can't
> reliably detect or fix whatever they've done wrong, because we're not
> the filesystem; they need to do it themselves.

I agree with that : everything cannot be undone, but I think that a  
good subset of the operations can (already) be undone.

  - commit (rollback)
  - pull   (rollback)
  - update (update ...)
  - merge  (update ...)
  - ...

It would make sense to have a single command to undo these operations  
in a consistent way.

> Even trying to specify what should happen in an ideal world is hard.
> What if someone does a "hg rename" of a file to a new name, then fills
> the renamed file with junk, then decides they want to "undo it"?  What
> should get undone - the filling with junk, or the rename?  If the  
> rename
> is to be undone, should the junk be copied back to the old name of the
> file, or left alone?  If it should be copied back, what if the user
> doesn't notice and commits the junk?

This is a good example of something that is quite difficult to undo.  
In this case, I would say that the "hg rename" should be undone (so  
the file gets back to its previous name).

The general principle I would see is that hg could have a "stack" of  
transactions (operations made by hg in current repository), and that  
"hg undo" could simply undo the last transaction on the stack, and  
pop it out. Each "transaction undo" operation, could give warnings or  
event refuse to be executed without being forced, because the working  
directory seems "strange".

I would be happy to contribute to the implementation of such a feature.

> Anything that purports to automatically undo a user error has to be
> predictable and always get it right, otherwise it's worse than having
> nothing at all.

I totally agree.

  -- Sébastien