Help designing the evolve UI

Angel Ezquerra angel.ezquerra at gmail.com
Thu Apr 17 10:32:06 CDT 2014


On Thu, Apr 17, 2014 at 5:27 PM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
>
> 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.

OK, but I'd just like to warn you that these things are a bit like
cement. They start liquid and then all of a sudden they become solid.
Defaults are important.

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

To tell you the truth this has not been a big issue for me in my
mercurial usage. Maybe that is because I use TortoiseHg 95% of the
time.

Angel


More information about the Mercurial-devel mailing list