[PATCH 1 of 1 V3] revert: improve abort messages if --all is not specified

[Matt Mackall]

On Tue, 2011-06-14 at 20:12 +0200, Adrian Buehlmann wrote:
> # HG changeset patch
> # User Adrian Buehlmann <adrian at cadifra.com>
> # Date 1308074809 -7200
> # Node ID 2ca10d93b81f4d87bceae22ed0904030960a45c4
> # Parent  4aef71839337c5548eba07f6e76d9b002d31ad70
> revert: improve abort messages if --all is not specified
> 
> We now provide tailored abort messages, depending on the situation.

Sorry I didn't get around to responding to your earlier question about
how to do this with less frustrating round trips.

I guess the answer to that is: a) do less per patch and b) bikeshed via
a low-latency medium like IRC.

There are parts of this patch that I'd accept, but overall I think
you're trying to put too much polish on this by drawing too many
distinctions.

> uncommitted merge:
> 
>   $ hg revert
>   abort: uncommitted merge

Is that why we abort? No. We don't care about that at all at present.
See below.

>   (use 'hg update -C .' to cancel the merge and lose all your changes)

How does a user discover that revert -a also works here?

> uncommitted changes:
> 
>   $ hg revert
>   abort: uncommitted changes

Well of course there are uncommitted changes. The whole point of revert
is to destroy uncommitted changes.

The point of -a is to prevent someone from doing:

 hg revert <return>foo # OMG STOP STOP STOP

rather than

 hg revert <shift>foo

-OR-

just running revert because they assume everything is soft and cuddly
and will just automatically "undo" whatever they did last.[1]

We will happily revert anything provided you just tell us what, so we
shouldn't be dishonest about our motives here, otherwise the user can be
justifiably be surprise when they later discover we didn't care about
their uncommitted change when they revert something by name.

I think the current message here is fine, though I think we can improve
the hints.

>   (use --all to lose all your changes)

Sure.

> uncommitted changes, revert to non-parent:
> 
>   $ hg revert -r 2
>   abort: revert to 946c41063461 modifies all files to match that revision

Again, that's not true.

>   (use update, or --all to lose all your changes)

Sure.

> clean, revert to non-parent:
> 
>   $ hg revert -r 2
>   abort: revert to 946c41063461 modifies all files to match that revision

Same story.

>   (use update, or --all to force)

Sure. Except it's not really forcing anything. We'd just as happily
comply if you specified '.'.

It's like the difference between a circular saw which has two buttons
you have to press to get it to go, and an electrical socket which simply
has recessed holes so you don't zap yourself by brushing against it.

> nothing changed:
> 
>   $ hg revert
>   nothing changed

Is that new? I guess that's fine.


[1]
Q: why don't we do this for rollback then? 
A: because we weren't smart enough in the era when rollback was
introduced and people have been using rollback for magic in scripts and
finger macros since the beginning



-- 
Mathematics is the supreme nostalgia of our time.