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

[Gregory Szorc]

On Mon, Mar 20, 2017 at 8:17 AM, Ryan McElroy <rm at fb.com> wrote:

> Any objections here?
>

No. I agree with your approach here. Implement the granular knobs first.
Then build the "multiknobs" later.



>
> 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
>>
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170321/2f6c276f/attachment.html>