[PATCH evolve-ext] fold: add argument to handle ambiguous case

[Pierre-Yves David]

On 05/28/2015 03:25 PM, Jordi Gutiérrez Hermoso wrote:
> On Thu, 2015-05-28 at 14:01 -0700, Laurent Charignon wrote:
>> # HG changeset patch
>> # User Laurent Charignon <lcharignon at fb.com>
>> # Date 1432845532 25200
>> #      Thu May 28 13:38:52 2015 -0700
>> # Node ID 0821817a84792210498107777181dcc9f1d68ec7
>> # Parent  69e5de3e6129185469c2cbf98383ac6d58260d0c
>> fold: add argument to handle ambiguous case
>>
>> Before this patch, when a user was using fold for the first times he could
>> think that --exact is the default behavior and make a mistake.
>> For example hg fold -r 12+13 won't just fold revision 12 and 13 together but
>> 12, 13 and the linear chain of revision upto the working directory's
>> parent.
>
> Yes, this is quite intentionally the fold behaviour. Pierre-Yves and I
> hashed it out a while ago.

Laurent pointed to me that he foot-gunned himself with the current 
behvior expecting '--exact' to be the current behavior. I explained him 
(for context) how we came to the current behavior (majority of observed 
use case are: `hg fold `(.~X)::.`). But I'm unhappy of seeing user 
shooting themself in the foot. So if he is giving a shot at trying 
something more safe.

>> This patch introduces a new option when the selection is ambiguous:
>> when the user specified two or more revisions not including the
>> working copy's parent without using --exact flag.
>
> Your definition of ambiguous doesn't match what Pierre-Yves and I had
> in mind when we discussed this behaviour before. For example, `hg fold
> -r 'draft() and tag()'` is a completely reasonable thing to do, may
> select more than one commit, and it should fold with the current
> commit. There are other revsets that could operate similarly and
> should not be considered "ambiguous".

I think Laurent approach here is "if there is multiple revs, this is 
suspicious and I ask for details". I'm not sure if I'm sold yet, but 
this is much better than "have different behavior accorting revset result"

> I really think the current fold behaviour should stay. An error with
> fold is easy to undo using `hg touch` and `hg prune --succ`. There is
> a way out, and we should nudge users towards not using `hg fold
> --exact` by default. I worked on making the fold docstring short
> enough to be clear and not tl;dr.

We definitly aims at having an easy way to restore things to a previous 
state. But the current User experience for it is atrocious so we have to 
take some of that in account not. However this should not dictate the 
final shape of the UI (yes, some contradiction here, my point is "do not 
pretend restoring is 'simple'").

-- 
Pierre-Yves David