Standardizing config option naming

Martin Geisler mg at aragost.com
Thu Aug 11 05:10:10 CDT 2011


Matt Mackall <mpm at selenic.com> writes:

> So we've been fairly inconsistent with naming config options. It's
> time to lay down the law here. And based on existing usage, the law
> should be: no separator on new options.

I like "foo-bar" much more than "foobar" and I've though of simply
letting "-" and "_" be invisible: so the user can write "foo-bar" (and
we would document it as such) but an old "foo_bar" or "foobar" would
still work since the code uses "foobar" internally.

I didn't come up with this out of the blue: zsh ignores all underscores
in options:

  http://zsh.sourceforge.net/Doc/Release/Options.html

> (My favorite is this one: web.allow_push vs web.allowpull)

Yeah, that's a classic :-)

> We should probably figure out how to normalize the existing options in
> a backward-compatible way. This means removing the separators from the
> docs and adding some sort of compatibility fallback for the old option
> names. Though we need to be aware of conflicts like 'hooks.premerge'
> (standard merge hook) vs 'hooks.pre-merge' (generic command hook).

That is what stopped the above idea, plus the fact that there are some
sections where the keys are freeform, such as merge-patterns. Maybe that
could be solved by marking some sections as having significant keys?

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/


More information about the Mercurial-devel mailing list