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

[Laurent Charignon]

On 5/28/15, 3:25 PM, "Jordi Gutiérrez Hermoso" <jordigh at octave.org> 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.
>
>> 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".

Sure and it will because the working copy is in draft(), right?

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