Undo a commit?

rupert.thurner rupert.thurner at gmail.com
Thu Jul 16 00:01:48 CDT 2009


On 15 Jul., 15:11, Hans Meine <me... at informatik.uni-hamburg.de> wrote:
> 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?

on one hand the advertisments say:
the big advantage of distributed systems is "just clone and
hack along, if something goes wrong, clone again". so the workflow
can be much more experimental so to say.

otoh there often terminology like "shoot oneself in the foot",
"dangerous", "user too stupid" which then goes in a different
direction. our experience is that even beginners tend to bring
less errors in a central repository with mercurial than with
cvs/svn.

but you are right "backups" is probably not the right word for these
files.

for the merge you are also right, but it only tells you the way out
the first time. if one tries to solve it and much later figure "no
i cannot handle this - lets undo" mercurial does not help.

>
> > 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.

that is true :)

> > 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.

this is unfortunate i think, as mercurial is not yet legacy. but maybe
this
strategy will make it legacy much earlier ;)

> extensions is already a very good method to reduce complexity IMO.
>
> HTH,
indeed, that helped a lot, many thanks! will look for a wiki page
with this on it, and if i do not find one i try to create one.

rupert



More information about the Mercurial mailing list