[PATCH 1 of 4] obsolete: add an `ui.prevent-unstable` option and related function

Pierre-Yves David pierre-yves.david at ens-lyon.org
Fri Dec 28 21:33:28 CST 2012


On 29 déc. 2012, at 01:28, Pierre-Yves David wrote:

> 
> On 29 déc. 2012, at 01:00, Matt Mackall wrote:
> 
>> On Fri, 2012-12-28 at 23:44 +0100, Pierre-Yves David wrote:
>>> # HG changeset patch
>>> # User Pierre-Yves David <pierre-yves.david at ens-lyon.org>
>>> # Date 1356728772 -3600
>>> # Node ID 84a2e3e8a7123f6d2593a4c78cca4399d77538b8
>>> # Parent  8019f96ec4ce96f97dde775fe6f45007f29dabc3
>>> obsolete: add an `ui.prevent-unstable` option and related function
>> ...
>>> Rationale:
>>> 
>>> With obsolescence marker it is technically possible to rewrite a changeset
>>> without taking care of its descendants. Advanced user want to benefit from that
>>> but it seems a bad idea to expose that to new user.
>> 
>> And what's the rationale for an advanced user wanting to do that?
> 
> Advanced user want to focus on what they are current rewriting and handle the consequence on descendant later. When they have a better understanding of what they changed.
> Such workflow is similar to the one MQ use. You qrefresh you current patch only and care about consequences later.
> 
> Eg: refactoring branchmap have consequences on filtering related changesets. I have no willingness to handle consequence on them until I'm done refactoring.
> 
> Other useful usecase is `hg rebase -r` that allows you to extract a changeset from a series.
> 
> Other early user of evolve can testify they do that all the time.


After discussion with Matt and Siddhart I'll drop the option.

If obsolete is enabled we allow unstability creation.

The proper default will be discussed at the sprint.

-- 
Pierre-Yves


More information about the Mercurial-devel mailing list