Re: [PATCH 1/2] parse-options: allow for configuring option abbreviation

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Mar 26, 2019, 11:00 UTC
Message-ID: <87ef6tc33c.fsf@evledraar.gmail.com>
In-Reply-To: <CACsJy8BpToq2VAzFo61dz7Hco42Sbka5qQm3ACn_6aejUxAKOg@mail.gmail.com>

On Tue, Mar 26 2019, Duy Nguyen wrote:

Show 19 quoted lines

> On Tue, Mar 26, 2019 at 1:29 PM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>> I don't see how a new "abbreviatedOptions" is plausibly going to crowd
>> out anything else, sounds pretty unambiguous to me.
>
> By crowded I mean a lot of configuration variables under "core"
>
>> By my count out of the the existing GIT_* variables in git.txt around
>> 1/3 are already configurable via config, another 1/3 (all the GIT_TRACE
>> stuff) is something we've wanted to have configurable in the past (but
>> nobody's gotten around to writing patches for).
>>
>> I think it's fair to say that when we normally add user-configurable
>> stuff we do it as config, not as new env vars.
>
> I disagree that not every configuration knob has to be a configuration
> variable, especially when core.* more or less becomes a dictionary
> that you can't really read anymore (unless you know the key to look
> for). But I see you're dead set on adding config vars. Go ahead.

I don't mean to pile on in this thread, and cards on the table: In terms of stuff I can be bothered to write a patch for and stuff I *really* want in git, this thing is maybe on a 2/10 out of a 1-10 scale.

I.e. I'd use it, and it would probably save my ass *somewhere* down the line, the motivation was being bitten in the past, so once I spotted Johannes's series I was reminded to clean it up & submit it. But I wouldn't care enough to carry a forked git with this (unlike some other stuff).

I just wanted to elaborate *in general* on the question of "why config and not env".

I don't think everything we find reason to add a knob for needs to be a config variable. E.g. I can't think of a reason for why the GIT_*_PATHSPECS variables should be. That seems like the sort of thing you'd only tweak for a *specific* git invocation. I wouldn't oppose it being config if someone had a compelling reason & patch, but can't think of one myself.

What I wanted to get across in the above replies to you/Eric, but probably did a bad job of is that separate & aside from the merits of any given new config variable there's the problem of being a "zookeeper" with large git installations.

I.e. you don't even pick the animals, or feed them, but if the zoo's on fire or overflowing with poop it's your problem.

So I have some servers where I'm in charge of maintaining/upgrading git, and it's on me if crap breaks in the aggregate, but I'm not writing anyone's individual scripts for them, and the runtime envs for those might be varied.

It's for those sorts of cases where having the flexibility of turning something on either in the env or via system-wide or user-wide config is handy. I.e. in this case I might say:

    "You can run your scripts, but you'll be in 'strict mode' and need
    to spell out your options, because I'm not getting out of bed if
    your random job using git breaks because you were lazy and did a
    'git init --ba'".

I don't think this is a use-case that's obvious, so it's worth elaborating on it. I suspect a lot of devs/users on this list have advanced git use-cases, but they're all ones where the git processes they care about/need to maintain run as a child of their login shell, or equivalent. In that case the config v.s. env var distinction mostly doesn't matter.