"How I got bitten when merging" scenario

[Sébastien Pierre]

Le 06-05-06 à 03:05, Christian Boos a écrit :

> Sébastien Pierre wrote:
>> And here, I am now at v4, and v5 was "uncommited" from the  
>> repository.
>> No "redo" to "undo the undo", so I guess my v5 changeset is lost.
>
> The "hg help undo" message can't be any clearer about this.

My point is to illustrate what a newbie would probably do. As I am  
relatively fresh to Mercurial, I tend to do mistakes that regular  
users do not make anymore... and I think this helps spot usability  
problems.

> Maybe each command should suggest a way to "undo" what it does,
> when this is possible, e.g: "commit" and "pull" would refer to "undo",
> "add" and "remove" to "revert", "merge" to "update -C" ("reset"? :) ).

I would personally tend to think that "undo" should simply undo the  
last command, whatever it was. And it would be even better if there  
was a "redo" command.

I don't see why Mercurial "undo" should behave differently from most  
(desktop) application. Maybe someone can explain why it should ?

>> I know that this is probably no kosher use of Mercurial, but it  
>> can be
>> pretty confusing, and especially the last "undo" that actually undoes
>> the commit and not the merge.
>>
>> I would have expected the command sequence for this scenario to work
>> like this:
>>
>> $ hg update -C 5     (go back to v3.a)
>> $ hg merge           (merge with the tip
> $ hg update -C 6     (go back to v5)
>
> Here another situation where I think an explicit "hg reset" command  
> would have made things more intuitive.

True. This is why I really liked your proposition. However, this  
introduces another command for what undo should do.

I perceive Mercurial user-interaction as "minimalistically  
designed" (which I actually like a lot), and would also like to see  
this design strategy in the number of available commands (and get rid  
of/transform what is not necessary, or what is confusing).

  -- Sébastien