Help designing the evolve UI

[Colin Caughie]

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.

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.