"commit --amend" and extraneous files

[Victor Sudakov]

Steve Fink wrote:
> > > 
> > > > If I wanted to commit just several files:
> > > > 
> > > > hg commit -m "Foo" file1.c file2.c
> > > > 
> > > > and instead committed the whole working dir:
> > > > 
> > > > hg commit -m "Foo"
> > > > 
> > > > What is the right way to amend the problem (so that files other than
> > > > file1.c and file2.c become uncommitted again)?
> > > Check out `hg backout` and `hg histedit` (I think they require an
> > > extension.
> > I can also probably `hg strip` the tip revision, but are you sure the
> > desired effect cannot be achieved with "commit --amend" as stated in the
> > subject line?
> > 
> > And I don't want to use `hg backout` because I don't want to keep the
> > erroneous commit in the repo.
> 
> I think `hg commit --amend` always keeps the existing commit's changes, and
> just adds in new ones. So I guess you could do `hg revert -X file1.c -X
> file2.c` followed by `hg commit --amend`, but then you'd need to restore all
> your changes from the .orig files.

Yes, I did something like that, like "hg diff -c tip | patch -R" but had
to restore the changes from .orig files, as you say, and then "hg commit
--amend." I had also copied file1.c and file2.c to another location, to
be on the safe side.

All this turned out labour-consuming and ugly. Going with "hg strip"
would have been easier. It also automatically restores the working copy
to the previous version.

> 
> Perhaps something like `hg update -r tip^; hg diff -c tip | patch -p1` and
> then recreate your commit (and ignore or strip the old one)?

I would be afraid to "hg update" when the working copy is in erroneous state.

> 
> This is much easier with the evolve extension, which is how I would do it.
> I'd use `hg uncommit -a; hg amend file1.c file2.c` though I think it would
> work in a single command with just `hg uncommit -X file1.c -X file2.c`. (My
> brain has never managed to properly grasp the -I and -X options, so I always
> fall back to undoing everything and then redoing the individual pieces with
> `hg amend` or `hg amend -i`.)

Can you tell me why there are so many seemingly overlapping commands and
extensions for a similar purpose? There is "hg rollback", "hg uncommit",
"hg strip" and maybe more.

"hg backout" at least has a clear purpose: the fact of undoing some
changeset is kept in history.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49 at fidonet http://vas.tomsk.ru/