This has some interesting implications. Consider the case at hand:
git-stash --index is a boolean switch. It was not the default state,
and it lacked any configuration override, so there was no '--no-index'
switch provided. If we make this change to git, presumably EVERY
boolean flag like this in all the git subcommands needs to be backed
with a '--no' counterpart.
Thinking this through a little further, there is the potential to want
to override the configured value (in the case of non-booleans) with an
explicit command line switch. So now we have "precedence rules" for
subcommand options. Probably simple to handle this for single vars,
but harder for multivars.
My $0.02,
David
On May 12, 2011, at 7.35 , Michael J Gruber wrote:
Mechanism
=========
I propose the following mechanism for setting default command line
options from the config:
options.<cmd> = <value>
is a "multivar" in git-config speak, i.e. it can appear multiple
times.
When running "git <cmd> <opts>", our wrapper executes
git <cmd> <values> <opt>
where <values> is determined by the following rule in pseudocode:
if $GIT_OPTIONS_<cmd> is unset:
<values> := empty
else:
for <value> in $(git config --get-all options.cmd):
if <value> matches the regexp in $GIT_OPTIONS_<CMD>:
append <value> to <values>
Examples
========
* By default, no options can be overriden from config (other than
those
which have config vars already, of course).
* A script which wants to protect options "foo" and "bar" of "cmd"
from
being set by config sets GIT_OPTIONS_CMD="!(foo|bar)".
* A script which wants to allow overriding options "foo" and "bar" of
"cmd" by config (but nothing else) sets GIT_OPTIONS_CMD="foo|bar"
NOTES
=====
* This can be done by commit_pager_choice() or by a call right after
that in those places.
* regexp notation/version to be decided
* We should probably do this for long options only (and insert
"--<value>" rather than "<value>" to spare the "--" in config).
* We should probably do a prefix match.
* We could use GIT_OPTIONS_<CMD>_ALLOW and GIT_OPTIONS_<CMD>_DENY
rather
than rely on negated regexps (if DENY matches deny, otherwise if ALLOW
matches allow, otherwise deny).
* We can get rid of a few config vars then...and may need to clean up
our option names.
Taking cover...
Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html