Re: [PATCH v3 1/3] repo-settings: create core.featureAdoptionRate setting

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jul 2, 2019, 10:53 UTC
Message-ID: <87r2787lms.fsf@evledraar.gmail.com>
In-Reply-To: <CACsJy8Cwxov9VWq_MpeWstGtMB-rTy6LYyFj_PF9oSP0kqcDXQ@mail.gmail.com>

On Tue, Jul 02 2019, Duy Nguyen wrote:

Show 19 quoted lines

> On Mon, Jul 1, 2019 at 10:32 PM Derrick Stolee via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
>> @@ -601,3 +602,22 @@ core.abbrev::
>>         in your repository, which hopefully is enough for
>>         abbreviated object names to stay unique for some time.
>>         The minimum length is 4.
>> +
>> +core.featureAdoptionRate::
>> +       Set an integer value on a scale from 0 to 10 describing your
>> +       desire to adopt new performance features. Defaults to 0. As
>> +       the value increases, features are enabled by changing the
>> +       default values of other config settings. If a config variable
>> +       is specified explicitly, the explicit value will override these
>> +       defaults:
>
> This is because I'd like to keep core.* from growing too big (it's
> already big), hard to read, search and maintain. Perhaps this should
> belong to a separate group? Something like tuning.something or
> defaults.something.

The main thing users look at is "man git-config" (or its web rendering) which renders it all in one page anyway.

I think in general adding more things to core.* sucks less than explaining the special-case that "tuning.*" isn't a config for git-tuning(1) (although we have some of that already, e.g. with trace2.*).

Documentation/config/core.txt is ~600 lines. Maybe it would be a good idea to split it up, similar to your split of Documentation/config/*.txt, but let's not conflate how we'd like to maintain stuff in git.git with a config interface we expose externally.

It's going to be very confusing for users if some settings that otherwise would be in core aren't there because a file in git.git was "too big" at the time. Users (mostly) aren't going to know/care in what chronological order we added config keys.