Help designing the evolve UI

[Pierre-Yves David]

On 04/17/2014 11:22 AM, Angel Ezquerra wrote:
> On Thu, Apr 17, 2014 at 5:05 PM, Pierre-Yves David
> <pierre-yves.david at ens-lyon.org> wrote:
>>
>>
>> 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)
>
> Aren't we discussing the evolve UI? If so, I may not be able to claim
> it with a 100% certainty, but I maintain that it is quite likely that
> evolve --all will be a more common operation than a single step
> evolve. I think others have said the same in this thread. So I'd
> prefer to have "hg evolve" and "hg evolve --next" instead of "hg
> evolve --all" and "hg evolve". This has nothing to do (IMHO) with
> exploring this new frontier.

Yes, we are discussing the evolve UI. And I'm taking a strong stand on 
"This is too early to change this specific point". And yet this has all 
to do with exploring a new frontier.

I would like to close the specific point 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.
>
> What other areas do you think need this (other than evolve)?

graft, rebase, histedit, evolve, merge, push/push, any evolve command 
with a --evolve flag, resolve, other stuff I've over looked.

-- 
Pierre-Yves