Re: [PATCH 00/11] [RFC] Create 'core.size=large' setting to update config defaults

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 6, 2019, 16:07 UTC
Message-ID: <xmqqv9xir92l.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <741a4e37-e5d6-829a-75ee-b9bc3f3b17b2@gmail.com>

Derrick Stolee <stolee@gmail.com> writes:

Show 12 quoted lines

>>  - perhaps we may eventually want to allow end users (via their
>>    ~/.gitconfig) and system administrators (via /etc/gitconfig)
>>    define such a macro setting (e.g. setting macro.largeRepoSetting
>>    sets pack.usebitmaps=true, pack.useSpars=true, etc.) *after* we
>>    figure out what we want to do to the other points in this list.
>>
>>  - even if we do not allow end users and system administrators futz
>>    with custom macros, can we specify the macros we ship without
>>    casting them in code?
>
> Are you suggesting that we allow some config values to be pulled from
> the repo contents?

Not at all. As far as the configuration is concerned, what project ships is tainted data that should not be used blindly.

What I had in mind is parallel to the idea of pushing "static struct userdiff_driver builtin_drivers[]" out of the compiled-in code and instead have a text file shipped in /usr/share/git/ somewhere. So, instead of having "core.size==large means these other four variables are set to these values" in the code, we invent a general mechanism to read such "macro" specification out of a text file, and that would be the only code change---the specific "core.size==large affects X, Y and Z" would not be in the code, but would be in the text file we ship and read by the mechanism.

If the list of allowed "meta" configuration variables and the configuration variables whose default each of them affects can be expressed in our usual ".gitconfig" file format, then the system administrators can add their own in /etc/gitconfig, too, to help their users.

That is what I meant by the last item. Note that I was "wondering if it makes sense" and what I wrote above in this message is merely clarifying what I meant---I am not making further/more arguments to claim it is a good idea (at least not yet).

Thanks.