Re: RFC proposal: set git defaults options from config

From: David Pisoni <dpisoni@gmail.com>
Date: May 12, 2011, 22:36 UTC
Message-ID: <2235D93D-4F02-42D7-88B1-74F692D58AA5@gmail.com>
In-Reply-To: <4DCBF01F.9040009@warpmail.net>

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:

Show 56 quoted lines

> 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