[PATCH 6 of 6 RFC] push: allow specifying default-push as defaultpush

Martin Geisler 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
>>
>>   [paths]
>>   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
'default-push'.

Arguing that 95% of our config keys use no separator would be such an
argument.

Note that we have come conflicts:

  pre-commit, precommit
  pre-outgoing, preoutgoing
  pre-tag, pretag
  pre-update, preupdate

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).

-- 
Martin Geisler


More information about the Mercurial-devel mailing list