Re: RFC proposal: set git defaults options from config

Jeff King venit, vidit, dixit 16.05.2011 13:02:

On Thu, May 12, 2011 at 04:35:11PM +0200, Michael J Gruber wrote:

quoted

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.

Yeah, sorry, I was a bit dense. I meant to activate it by default and
shut it off from git-sh-setup by default so that scripts are not
affected (but can choose to enable it selevtively).

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.

Yep.

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.

git-sh-setup

The phase-in is still needed for scripts which do use sh-setup, of course.

quoted

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)?

As a default for the phase-in-phase I was hoping that would be safe enough.

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).

quoted

* 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.

quoted

* 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.

Agreed!

quoted

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.

GIT_BE_STRICT_I_AM_BRITISH

Michael