Undo a commit?

[Hans Meine]

On Wednesday 15 July 2009 14:36:12 rupert.thurner wrote:
> and they do not understand the various concepts of "backup". one time
> its a .rej, then a .orig, then a bundle.

I would not call all these "backups".  Also, users should know already that 
mydocument.bak, myproject-20090320.tar.gz, and the tape in their cupboard are 
also different kinds of backups.  So what exactly is so confusing here?

> they learn that "purge"
> removes all these backups,

..if that (dangerous) extension is activated..

> but it is not valid for all of them, e.g.
> strip bundles.

..created by another (dangerous) extension..

> merges which are not done need to be stopped with up --
> clean.

correct.  OTOH, hg already tells this to the user IIRC, so that's not very 
difficult, is it?

> if one looks at the wealth of commands in mercurial, it became quite a
> challenge to get into it.

I found it quite simple, that is - it depends on the number of enabled 
extensions and on the complexity of the tasks you're trying to perform.
I tend to be much more ambitious with hg than e.g. with cvs/svn.

> just to name a couple of examples:
>
> * complicated command to do something simple and often needed:
>   hg qimport -r tip ; hg qrefresh -e ; hg qfinish tip

Indeed I often do this, but still I think it is not the first thing users 
should [need to] learn.  Often, "hg rollback" followed by <cursor up> for 
recalling the "hg ci -m ..." is a good substitute for fixing errors 
immediately after the commit (which is the most common situation) and does not 
require so much knowledge or any extensions at all.

Then, "hg histedit" may be more simple than MQ for many use cases.

> * different commands for approximately the same thing, e.g. undo/
> clean:
>   hg revert, hg backout, hg strip, hg rollback, hg update --clean, hg
> purge

I hardly ever use most of them.  "hg rollback" is common, and "hg revert" 
(without -r!) is probably the only other command on this list which I would 
teach a newbie.

> * asymetries:
>   hg branch to create a branch
>   hg commit to close it

Yeah, that's a little bit unfortunate.  Also, tags are quite special.
For example, "hg tag" modifies both the working copy (.hgtags) and the repo 
(i.e. performs an implicit commit).  Note that rollback will only revert the 
second effect, i.e. .hgtags will appear modified.

> what would be the best strategy to reduce the command and option set
> and make it more intuitive?

Unfortunately, backwards-compatibility seems to be too important to fix most 
of these problems.  OTOH, mercurials approach of leaving many tasks up to 
extensions is already a very good method to reduce complexity IMO.

HTH,
  Hans