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

[Augie Fackler]

On Mon, Mar 20, 2017 at 03:17:47PM +0000, Ryan McElroy wrote:
> Any objections here?

Hearing none, queued.

Do we still think that the 'compat' knob belongs here (as we thought
with [behavior]), or should it live under [ui]?

>
>
> 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