"commit --amend" and extraneous files

[Marcin Kasperski]

> Both "hg amend" and "hg uncommit" are separate experimental extensions.
> Why waste efforts on them?

This is the confusion I talked about. 

With evolve active, those commands exist as part of evolve and are 
important part of the whole evolve toolbox.

There also exist extensions which provide those commands as standalone,
mostly (I bet) to build possibility of consistent command set with and
without evolve.

 hg --config extensions.evolve=! --config extensions.uncommit= help uncommit
 hg --config extensions.evolve= --config extensions.uncommit=! help uncommit

for example.

> My workflow is not advanced enough to use evolve. 

Evolve needn't be treated as that advanced, really, can be used in a
simply way too. You need to amend your last commit from time to time
or fold few commits etc.

Without evolve, your commit --amend, histedit and similar commands
internally:
- create new fixed commit(s)
- strip old commit(s), possibly saving bundles in .hg in case recovery
  is needed

With evolve, the same commans:
- create new fixed commit(s)
- mark old commit(s) as obsolete

In normal case effect is practically the same (obsolete commits are well
hidden, not pushed etc) but if sth turns wrong they can be
reached and recovered (without evolve you may hunt for appropriate
bundle in .hg, with evolve you may display obsolete changesets and
operate on them as needed). Also, various new possibilities open like better
control when you fix commit which already have children. Or even, with
some effort, sharing obsolescency info between repos.

> I occasionally need to
> correct a commit message, or to fuse 2-3 successive commits into one. I'm
> quite happy with histedit so far.

As I said, evolved hg commit --amend or hg amend and hg fold would 
usually do the same, but simply open new possibilities. And, well,
hg uncommit handles the very case you had problem with (updating
commit via file removal).