Help designing the evolve UI

[Aurélien Campéas]

On 17/04/2014 11:57, Martin Geisler wrote:
> Aurélien Campéas <aurelien.campeas at logilab.fr> writes:
> 
>> On 17/04/2014 04:27, Pierre-Yves David wrote:
>>>
>>>
>>> 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.
>>
>> "replace" would have my preference, because of the binary
>> relation it expresses, which is absent from kill/prune.
>>
>> 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".

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'm also using hgview, which shows very clearly the troubled changesets.
Hence figuring myself what should be rebased is a non-issue.

Divergent changesets are not handled AFAIK.


Regards,
Aurélien.