Help designing the evolve UI

[Aurélien Campéas]

On 17/04/2014 16:33, Pierre-Yves David wrote:
> 
> 
> On 04/17/2014 10:29 AM, Aurélien Campéas wrote:
>> On 17/04/2014 16:05, Pierre-Yves David wrote:
>>>
>> [...]
>>>>>> 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)
>>>
>>
>> Ah, glad to hear it, maybe that was bad luck, but the few times I asked
>> evolve to solve a divergence I was said "no luck" .... Since then
>> I've learnt not to bother trying.
>>
>>> Evolving stuff one at a time is a strong feature of evolve.
>>
>> Maybe but "hg stabilize" should be abortable imho.
> 
> `hg up -C .`

Not equivalent. A whole rebase is abortable. One individual "evolve"
or "graft" messy state can be aborted with "update -C".

> 
> Current instrastructure for multi-step operation is Mercurial did not
> over anything out of the box. the current implementation of evolve is
> very hacky for now. But it does the job.

The rebase command provides such a feature. It does the job I need.

> 
> We would be happy to review your patches adding support for `hg graft
> --abort`. That would bring an initial solution.

Well, I would be very happy providing such patches, however there's no
mercurial core development in my current work assignments, so ...

> 
> 
>>
>> BTW, one feature I really miss is also the ability to "strip"
>> obsolescence markers (this is related to my point above).
> 
> NO. you do not miss the ability to strip obsolescence markers. Stripping
> obsolescence markers is bad, wrong, awful and the source of all evil.

Pierre-Yves, you shouldn't be so sure of what users want or need.

It regularly happens that I rebase some cset, only to realize I should
have left it untouched. But too late.

Now if I push, the new version will be pushed. It may create a
(probably harmless) divergence, or confuse a review tool.

I can of course just wipe .hg/stores/obsstore, and repull, and
then rebuild whatever additional obsolescence state I had before
the mistake but that can be tedious.

Stripping obsolescence markers is useful for the same reason strip
is useful (and to be used wisely & sparingly).

Now, if there are theoretical or practical objections to that,
I'd like to know them. I'm not, however, interested in anathems.

> 
> The feature you miss is a better story to revive changesets.
> 

I know how to use "hg touch" to revive changesets.
This is good enough as far as I'm concerned.


Regards,
Aurélien.