Help designing the evolve UI

[Pierre-Yves David]

On 04/17/2014 12:56 PM, Colin Caughie wrote:
> On 4/17/2014 9:33 AM, Pierre-Yves David wrote:
>>
>>
>> On 04/17/2014 12:29 PM, Colin Caughie wrote:
>>> On 4/17/2014 7:27 AM, Pierre-Yves David wrote:
>>>>
>>>>
>>>> On 04/17/2014 10:14 AM, Greg Ward wrote:
>>>>> On 17 April 2014, Angel Ezquerra said:
>>>>>> One of my biggest issues with the current evolve UI is that a
>>>>>> plain "hg
>>>>>> evolve" only evolves one revision. This surprised me a lot when I
>>>>>> first
>>>>>> tried the evolve command and it still annoys me every time I use it.
>>>>>
>>>>> Me too. I've just gotten in the habit of always running "hg evolve
>>>>> -a".
>>>>> The user guide I'm working on always says "hg evolve --all". Hmmm.
>>>>>
>>>>> +0.9 to making --all the default. Does it make any sense for
>>>>> "hg evolve -r REV" to evolve a single rev? Or maybe "hg evolve --next"
>>>>> to do what "hg evolve" currently does?
>>>>
>>>> --rev is something I've beed thinking for a long time. This would got
>>>> well along flags to select the troubles to fix. (waving at Jordi)
>>>>
>>>> Switching from --all to --next could be a valid change if the whole
>>>> proposal fix my concerns about discovery of step by step evolving.
>>>>
>>> Here's another possibility: what if evolve could detect when what is
>>> required is a simple rebase on top of an amended non-tip changeset
>>> (which I suspect it will be > 90% of the time), and if it is just do it
>>> using the existing rebase logic?
>>
>> Are you proposing a non-deterministic behavior?
>> If so -1
>>
> Definitely not. My suggestion hinges on there being a simple and
> deterministic way of deciding that the repo matches this 90% scenario,
> and only doing the rebase if it passes this test. If such a test is
> impossible then please disregard.

Ok, trying to understand you again then! (Not saying the blame is on 
your sidE)

> If there *is* a way to test for this then I don't think it's very
> different from "hg merge" refusing to proceed without arguments if there
> are more than two heads in the current branch, or "hg rebase" refusing
> to proceed without arguments if the intended source and destination
> aren't obvious.

I think evolve is already close to that. The multiple "heads" thing is 
actually interresting (do not evolve is there is more that one obvious 
candidate)

Thanks for pointing that out.

-- 
Pierre-Yves David