[PATCH] dispatch: use --section.setting=value instead of --config=section.setting=value

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue May 6 00:06:40 UTC 2014



On 05/04/2014 01:57 PM, Mads Kiilerich wrote:
> On 05/04/2014 09:31 PM, Augie Fackler wrote:
>> On Fri, May 02, 2014 at 06:24:07PM +0200, Mads Kiilerich wrote:
>>> # HG changeset patch
>>> # User Mads Kiilerich <madski at unity3d.com>
>>> # Date 1398943909 -7200
>>> #      Thu May 01 13:31:49 2014 +0200
>>> # Branch stable
>>> # Node ID a9669ccfde3af288ad4b186e4f2ce8672cad4412
>>> # Parent  e88b1ad2871cd900262cde1633b561996d28388d
>>> dispatch: use --section.setting=value instead of
>>> --config=section.setting=value
>>>
>>> Convenient shortcut, looks more elegant than --config and is a fine
>>> supplement
>>> to normal command line options.
>> It's cute, but I'm not a fan: it opens up pseudo-random command line
>> API surface area that strikes me as likely to cause
>> backwards-compatibility headaches in the future.
>
> Yes, it "opens up", but only for existing "APIs". What kinds of backward
> compatibility problems could that cause?
>
> I can only imagine that it will prevent us from using --.*\..* options
> for other purposes ... but why should we ever do that, unless it is to
> expose existing section.setting config values.

Cute, but sounds terrible idea in practice. different between the 
--realflag and --realflag.subconfig is going to be very confusing for users.

For the records here are the currently documented top level section config:

alias
annotate
auth
decode
encode
defaults
diff
email
extensions
format
graph
hooks
hostfingerprints
http
proxy
merge
patterns
merge
tools
patch
paths
phases
profiling
revsetalias
server
smtp
subpaths
trusted
ui
web
websub
worker

Multiple of them already conflict with existing common flag for common 
commands.

Strong -1 on this feature.

We can keep digging a nicer version of our config stuff is you feel like 
it is useful etc `--config.diff.git true`.

-- 
Pierre-Yves David



More information about the Mercurial-devel mailing list