[PATCH 2 of 2 v2] rebase: add flag to require destination

[Ryan McElroy]

Any objections here?


On 3/16/17 1:55 AM, Ryan McElroy wrote:
>
>
> On 3/14/17 8:26 PM, David Soria Parra wrote:
>> On Tue, Mar 14, 2017 at 05:56:16PM -0700, Ryan McElroy wrote:
>>> # HG changeset patch
>>> # User Ryan McElroy <rmcelroy at fb.com>
>>> # Date 1489538624 25200
>>> #      Tue Mar 14 17:43:44 2017 -0700
>>> # Node ID 8d8b783803f43d5e2d86916c39e9554139752fe6
>>> # Parent  2dc26c57e60e7e7bf46a276e8a498a9746bd9271
>>> rebase: add flag to require destination
>>>
>> This looks good to me. I was wondering if we want to provide separate 
>> knobs for
>> these commands which might lead to config overhead or provide more 
>> comprehensive
>> "ui" improvement knobs such as "commands.requiredest" to move people 
>> to a better
>> model in logical steps.
>>
>> e.g. I am a user who likes a slightly enhanced user experience. 
>> ui.compat= is a
>> bit too much for me, but update destinations is a good idea. Do i 
>> have to find
>> all places where we use destinations to update or do I want to select 
>> a logical
>> step?
>>
>> I personally think while fine granualar steps are nice, I'd probably 
>> lean
>> towards logical steps as it provides a more consistent behavior for 
>> users (e.g.
>> assume an extension Y that we don't know of can opt into using
>> "commands.requiredest", which at the moment it cannot unless it 
>> depends on
>> "commands.update.requiredest" which is missleading.
>
> I'm not against this direction, but I think what I have proposed here 
> is stillt he first right step. Once we have a bunch of granular knobs 
> like these ones, we can then work towards "multiknobs" when we have 
> the config registry concept to tie options together more, and then the 
> compatibility levels are just the biggest "multiknobs".
>
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org