Re: RFC proposal: set git defaults options from config

[Jeff King <peff@peff.net>]

On Thu, May 12, 2011 at 04:35:11PM +0200, 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>

As a user, how would I active this for all commands when not running a
script? I see why you defensively say "if unset, don't enable this
feature at all".  As a user, should I have to set GIT_OPTIONS_CMD for
everything that I want to configure? I hope not.

I think we need one extra variable to say generally "I am in strict
plumbing mode" or "I am in user mode". So you would want something like:

  if $GIT_STRICT is unset:
    <values> := $(git config --get-all options.cmd)
  else if $GIT_OPTIONS_<cmd> is unset:
    <values> := empty
  else:
    [match values by regex as you do]

But then you have a question of when GIT_STRICT gets set. An obvious
place is to set it in the git wrapper, so that "git foo" will have its
subcommands properly strict.

But that doesn't help scripts which are not called from the git wrapper;
they need to set GIT_STRICT themselves, so we need a phase-in period for
them to do so.

> NOTES
> =====
> 
> * This can be done by commit_pager_choice() or by a call right after
> that in those places.

Ah, so reading this, I have a sense that you were intending to make the
equivalent of GIT_STRICT be "am I running a pager" (or "am I outputting
to a terminal)?

Which is somewhat safer, as it is purely something for programs to opt
into. And as a heuristic, it's mostly good. I can come up with examples
where a script might not want to allow some options to be passed, even
though output is to the user, but they are probably stretching (e.g.,
something like "--allow-textconv" in a script that is meant to restrict
the users rights).

> * regexp notation/version to be decided

I think I would just as soon have a list of allowed options. We're
hopefully not doing the regex over the value of the option, like
"--pretty=foo is OK, but --pretty=bar is not". It seems like this
unnecessarily complicate the common case (you don't care what the value
is, but you have to tack on (|=.*) to every option matcher), and the
added flexibility is probably not going to be useful.

So I expect options regex are just going to look like:

  --(foo|bar|baz|bleep)

at which point we might as well just make it a list. And for the sake of
sanity, we may want to provide some default lists for scripts to OK,
like some minimal set of rev limiting options or something, so that
scripts don't end up specifying the same sets over and over.

> * We should probably do this for long options only (and insert
> "--<value>" rather than "<value>" to spare the "--" in config).

Yeah. Anything that doesn't have a long option and is useful enough to
be used in this way should probably get one.

> Taking cover...

I dunno. It's not so bad. But I think we probably want to start with an
environment variable to say "I am a script, be strict", let scripts
start picking that up, and then phase in the ability to turn on options
selectively.

-Peff