Re: RFC proposal: set git defaults options from config

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: May 16, 2011, 12:54 UTC
Message-ID: <4DD11E76.1010707@drmicha.warpmail.net>
In-Reply-To: <20110516110256.GB23889@sigill.intra.peff.net>

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

Show 28 quoted lines

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

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:

Show 11 quoted lines

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

Show 9 quoted lines

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

Show 30 quoted lines

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

Agreed!

Show 6 quoted lines

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