Rodrigo: for some reason, patchwork thinks you are Martin. Any idea why?
https://patchwork.mercurial-scm.org/patch/19133/
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 <mailto: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
<mailto:rdama...@google.com>>
> # Date 1489274373 28800
> # Sat Mar 11 15:19:33 2017 -0800 <tel:33%202017%20-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.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
