Help designing the evolve UI

Pierre-Yves David pierre-yves.david at ens-lyon.org
Thu Apr 17 09:05:54 CDT 2014



On 04/17/2014 09:45 AM, Aurélien Campéas wrote:
> On 17/04/2014 15:18, Martin Geisler wrote:
>> Aurélien Campéas <aurelien.campeas at logilab.fr> writes:
>>
>>> On 17/04/2014 11:57, Martin Geisler wrote:
>>>> Aurélien Campéas <aurelien.campeas at logilab.fr> writes:
>>>>
>>>>> About the "evolve" command ... right now I avoid it completely since
>>>>> (iirc) it does nothing you can't do with other existing mercurial
>>>>> commands (including graft/rebase).
>>>>>
>>>>> Is it needed at all ?
>>>>
>>>> I think it's not technically needed, but without it, you'll have to
>>>> do the computer's job of figuring out what the right sequence of
>>>> rebases needed.
>>>>
>>>> I love that I can update to a non-head commit, 'hg commit --amend' it
>>>> and then let Mercurial figure out what needs to be rebased on top of
>>>> what to fix the history.
>>>>
>>>
>>> Maybe in theory. But with the current "evolve" command implementation,
>>> it's not that clear. It seems the only thing it understands is when to
>>> "stabilize".
>>
>> That is also almost the only case I've used it for.
>>
>>> In this case, it tries to graft changesets one by one, which is not
>>> always the most sensible thing to do; quite often, rebasing in one
>>> stride is the right thing, for two reasons:
>>>
>>> * I'm not interested in cherry-picking
>>> * I want to abort the whole rebase (and "evolve" cannot be aborted) upon
>>>    realization that I've created a complicated merge conflict and need
>>>    to step back.
>>
>> I actually thought it ran rebase for me. Rebasing is also done as a
>> sequence of merges and I actually think that rebasing is the same as
>> repeated grafting plus strip these days.
>
> The doc actually says:
>
> - rebase unstable changeset to make it stable again,
>
> Now, looking at the evolve implementation, I see graft being used.
>
> But rebase can be aborted, not graft/evolve.
>
> Moreover, the evolve extension patches graft & rebase to replace
> stripping with obsoleting. That makes graft quite redundant.
>
>
>>
>>> I'm also using hgview, which shows very clearly the troubled
>>> changesets. Hence figuring myself what should be rebased is a
>>> non-issue.
>>
>> Okay, good point.
>
> BTW (Angel, are you reading me ?) it would be nice if THG gave
> some visual hints also ....
>
>>
>>> Divergent changesets are not handled AFAIK.
>>
>> Yeah, I remember running into a situation where the extension basically
>> said "sorry, I don't know how to solve this" :)
>>
>
> And I suspect it won't ever know what to do :)

We do! the basic logic is implemented. Some preliminary step of more 
complicated case are just not implemented yet (because more urgent stuff 
are being handled first)

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list