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