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

From: Jakub Narebski <jnareb@gmail.com>
Date: Jul 4, 2019, 22:47 UTC
Message-ID: <86ftnl1kod.fsf@gmail.com>
In-Reply-To: <CACsJy8Cwxov9VWq_MpeWstGtMB-rTy6LYyFj_PF9oSP0kqcDXQ@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

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.

I'm not sure if I consider core.* too big. Well, there are 55 or more entries in this namespace.

Show 9 quoted lines

>> +If the value is at least 3, then the following defaults are modified.
>> +These represent relatively new features that have existed for multiple
>> +major releases, and may present performance benefits. These benefits
>> +depend on the amount and kind of data in your repo and how you use it.
>
> Then instead of numeric values, maybe the user should write some sort
> description about the repo and we optimize for that, similar to gcc
> -Os optimized for size, -Ofast for compiler speed (-O<n> is all about
> execution speed).

I also do not like those magic numbers.

Show 6 quoted lines

>
> We could write, for example, tuning.commitHistory = {small, medium,
> large} and tuning.worktree = {small, large, medium} and maybe
> tuning.refSize and use that to optimize. We can still have different
> optimization levels (probably just "none", "recommended" vs
> "aggressive" where agressive enables most new stuff),

I think we have three different things that are currently conflated in one config variable and one value.

First is what we want to optimize for; is it on-disk repository size, command performance / execution speed, or maybe convenient information.

Second is what type of repository we are dealing with. Is there a problem with long history, large number of files in checkout, large and/or binary files, or all together? The original `core.size=large` (or proposed core.repositorySize) was all about this issue. Another issue that might be important is that if it is leaf developer repository, or is it maintainer repository, etc. (which affects for example how the push looks like).

Third is what tradeoffs we are willing to accept to get required performance. Are we willing to use additional stable optional features; are we willing to use new experimental optional features; are we willing; are we willing to sacrifice convenience (ahead/behind information in status, information bout forced updates in push output, etc.) for performance? This what current proposal is about.

It may not nnned to be a separate confi variable for a separate aspect; it may be enough to have value that is space-separated list, or something like that.

Best, -- Jakub Narębski