How I deleted my new files with good help from Mercurial

[Daniel Carrera]

On Mon, Jun 28, 2010 at 8:23 PM, Matt Mackall <mpm at selenic.com> wrote:
> That's fine and as designed. Backout is basically three steps rolled
> into one:
>
> - update -C <rev>
> - revert -r <parent of rev>
> - commit
>
...
>
> Of course. This is -the only way to lose history- with core Mercurial.
> Spreading the blame to other commands is pointless.

I've thought about this, and this is what I think:

It is wrong for backout to modify the working directory. This
behaviour is unexpected and dangerous, as it will destroy uncommitted
data. I never would have expected that you had to destroy my
uncommitted changes in order to enter a commit that does the opposite
of a commit that is already in the repository. I figure that Mercurial
already has all the information it needs to make a "reverse" commit,
why would it mangle my working directory without warning?

In general, I also think that if you abort a command, that should mean
that the command does nothing. If a command destroys your uncommitted
changes even if you abort, I think there is a problem. And if it is
not possible to make commands behave in this way, I think that that
points to a design problem.

Daniel.
-- 
No trees were killed in the generation of this message. A large number
of electrons were, however, severely inconvenienced.