Help designing the evolve UI

[Pierre-Yves David]

On 04/17/2014 11:01 AM, Angel Ezquerra wrote:
> On Thu, Apr 17, 2014 at 4:14 PM, Pierre-Yves David
> <pierre-yves.david at ens-lyon.org> wrote:
>>
>>
>> On 04/17/2014 05:14 AM, Angel Ezquerra wrote:
>>>
>>>
>>> El 17/04/2014 04:28, "Pierre-Yves David" <pierre-yves.david at ens-lyon.org
>>> <mailto:pierre-yves.david at ens-lyon.org>> escribió:
>>>
>>>   >
>>>   >
>>>   >
>>>   > On 04/16/2014 09:47 PM, Greg Ward wrote:
>>>   >>
>>>   >> +1 to "prune": "kill" is a bad name. I think "obsolete" can
>>>   >> technically be used as a verb... but let's not. "prune" is good.
>>>   >
>>>   >
>>>   > `kill` is a terrible terrible terrible subcommand name.
>>>   >
>>>   > I figured that out the day I forgot the `hg` part of `hg kill -1`…
>>>   >
>>>   > The prune alias appear in the next hour as the official name.
>>>   >
>>>   > Prune get along nicely with "graft"
>>>   >
>>>   > --
>>>   > Pierre-Yves
>>>
>>> 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.
>>>
>>> The reason is that I relate "hg evolve" to "hg rebase" and "hg rebase"
>>> rebases all until it finds a conflict. So I think that for consistency's
>>> sake it would be best if hg evolve evolved all. There cities be a flag
>>> to evolve a single revision instead.
>>
>>
>> Evolving stuff one at a time is a strong feature of evolve.
>>
>> The one at a time workflow have massive advantage over the "at-once" +
>> "all-of-them" workflow.
>>
>> I want to make sure users discover this ability and are encouraged to use
>> it.
>>
>> I'm not exactly sure what the final API/behavior should be. But step by step
>> should be easy to do and discover.
>>
>> VCS→DVCS analogy: "Why would do we need push/pull? Why would one ever want
>> to have a commit local only?"
>>
>> Beside the philosophical backing of this behavior,
>
> I disagree with this assessment. I think that the parallel between
> evolve and rebase is much stronger than with pull / push. I'm not
> saying that it is not important to be able to evolve one revision at a
> time. It definitely is. I am saying that evolving all revisions is the
> most common case. It should thus be what the evolve command does by
> default.

I think you misunderstood my point:

- We have a whole new frontier here, I would like people to explore it.
- You cannot claim "most common case" in this brand new world. 
(corollary: no decision about it now)

>> the current
>> infrastructure in Mercurial for doing multiple step operation is barely
>> exist.
>
> It could be better but I don't think it is that bad. For example you
> can easily abort a rebase when there are conflicts.

Yes, because significant effort have been put in the rebase code to 
handle the whole rebase steps. And this is rebase specific.

We have not generic and easy to plug things yet.

-- 
Pierre-Yves David