On Mon, Mar 20, 2017 at 8:17 AM, Ryan McElroy <r...@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 <rmcel...@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@mercurial-scm.org >> > > _______________________________________________ > Mercurial-devel mailing list > Mercurial-devel@mercurial-scm.org > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel >
_______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel