On Wed, Mar 22, 2017 at 3:50 AM, Ryan McElroy <r...@fb.com> wrote: > Rodrigo: for some reason, patchwork thinks you are Martin. Any idea why? > https://patchwork.mercurial-scm.org/patch/19133/ > No idea, but I'm using a script he created for mailing patches directly to gmail's backend servers (to avoid reformatting) - Martin, any chance you hardcoded your own address there? :)
On 3/14/17 10:16 PM, Rodrigo Damazio via Mercurial-devel wrote: > > 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") > > > Note that I copied the notes over the the wiki for posterity: > https://www.mercurial-scm.org/wiki/4.2sprint/Notes > > If people do some cleanup passes and categorization, that would be useful. > I may contribute here at some point as well. > > > 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 > > > > While I like this initial direction, I think this needs to be turned into > a series of smaller steps, and we need more discussion around whether we > will revive the defaults section or keep it deprecated. I'll drop this from > patchwork for now while we discuss. > No problem. How/where/when/what would you like to discuss?
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