Jeff King venit, vidit, dixit 16.05.2011 13:02: > 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: > > 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. >> 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). > >> * 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! >> 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 -- 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