On Tue, Jul 02 2019, Duy Nguyen wrote: > On Mon, Jul 1, 2019 at 10:32 PM Derrick Stolee via GitGitGadget > <gitgitgadget@xxxxxxxxx> 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.
