[PATCH 6 of 6 RFC] push: allow specifying default-push as defaultpush
martin at geisler.net
Thu Aug 8 02:42:48 CDT 2013
Augie Fackler <raf at durin42.com> writes:
> On Wed, Aug 07, 2013 at 06:06:53PM +0200, Martin Geisler wrote:
>> Kevin Bullock <kbullock+mercurial at ringworld.org> writes:
>> > On 2 Aug 2013, at 9:15 AM, Augie Fackler wrote:
>> >> # HG changeset patch
>> >> # User Augie Fackler <durin42 at gmail.com>
>> >> # Date 1374709814 14400
>> >> # Wed Jul 24 19:50:14 2013 -0400
>> >> # Node ID d59a05f3c4e013ecf9c7d3b40c04fa9900b7f74f
>> >> # Parent 4c9c2538d46bed89734a465ae01dbda483154425
>> >> push: allow specifying default-push as defaultpush
>> > Unlike the rest of the series, this one causes us to change the output
>> > -- on one of our most well-publicized config options. I guess I'm -1
>> > on this until we're ready to officially favor the
>> > non-hyphenated/-underscored forms. Rest of the series looks fine to
>> > me.
>> Why would you even prefer the non-hyphenated versions? I know we use
>> names without underscores in the Python code, but I think someone needs
>> to explain how the arguments for that carry over to the config keys.
>> I think that having no underscores or hyphens comes at a cost in
>> readability and our docs might look more friendly if people see
>> default-push = http://...
>> instead of the version without a hyphen. I realize, though, that we have
>> a lot more options with run-together words.
> As we add configuration options, they will be without dashes or
> underscores, and it'd be nice to slowly converge on a single format
> instead of the patchwork quilt we have now.
I understood that it's nice to make the options consistent.
What I tried to ask is why you prefer the config keys without a
separator (hyphen/underscore)? In other words, I was hoping that someone
would explain why 'defaultpush' is a better config key than the current
Arguing that 95% of our config keys use no separator would be such an
Note that we have come conflicts:
We might want to add a new name for the 'prefoo' keys, maybe like
'control-foo' or something like that (we'll of course keep parsing the
old 'prefoo' key, but we can drop it from the documentation).
More information about the Mercurial-devel