On Tue, Mar 14, 2017 at 12:50 PM, David Soria Parra < d...@experimentalworks.net> wrote:
> On Sat, Mar 11, 2017 at 06:03:30PM -0800, Rodrigo Damazio Bovendorp via > Mercurial-devel wrote: > > # HG changeset patch > > # User Rodrigo Damazio <rdama...@google.com> > > # Date 1489274373 28800 > > # Sat Mar 11 15:19:33 2017 -0800 > > # Node ID 8c833b81a994e2d3304c3b06793f536355528aab > > # Parent 62939e0148f170b67ca8c7374f36c413b67fd387 > > fancyopts: making config defaults actually override defaults > > > > Overall this LGTM, and clearly makes defaults much better :). My concern > is that we are encouraging the use of defaults again, while they are > deprecated. Defaults have inherent problems that they overwrite arguments > which might be mutable exclusive with others (e.g. --graph in incoming > and outgoing), or lead to undesired behavior if it's set by an admin. an > exmaple > is if you would specifiy defaults.update.check=True, the user will not > find an > --no-check option in the help message or anywhere else. This is not a > problem if > we assume defaults are alway set by the user and he knows about them. > Thanks for the review. Yes, we discussed the update --check case specifically during Sprint: https://public.etherpad-mozilla.org/p/sprint-hg4.2 (search for "Flags and defaults breakout") The conclusion was that this gains us the ability to do proper single-flag overrides, which is good, but doesn't solve all the issues. There are other changes we also want to make flags and defaults useful again: - make the passed-in flag values not be simple primitive types, but rather enhance them with addition information about where the value is coming from, so commands like update can decide that an explicit --clean overrides a system default of --check, and should only fail if both come from the same level - we want to add a --no- counterflag for every flag, not just booleans, as a way to unset it (useful for revision-specifying flags for instance) - we want to add environment variables to the stack of overrides along with the different levels of config files and command-line arguments - we want to try making all positional arguments map to flags (e.g. "hg update 123" would be equivalent to "hg update -r 123" by making 123 be passed to the command as the -r flag, also allowing config overrides for those) - we want to investigate why we support callables in flag defaults, and remove support if that's not useful to anyone
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
