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

>
>
> On Wed, Jun 19 2019, Derrick Stolee via GitGitGadget wrote:
>
> >  core.commitGraph::
> >       If true, then git will read the commit-graph file (if it exists)
> > -     to parse the graph structure of commits. Defaults to false. See
> > +     to parse the graph structure of commits. Defaults to false, unless
> > +     `core.featureAdoptionRate` is at least three. See
> >       linkgit:git-commit-graph[1] for more information.
> >
> >  core.useReplaceRefs::
> > @@ -601,3 +602,21 @@ 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:
> > ++
> > +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 present significant performance benefits. They do
> > +not modify the user-facing output of porcelain commands.
> > ++
> > +* `core.commitGraph=true` enables reading commit-graph files.
> > ++
> > +* `gc.writeCommitGraph=true` eneables writing commit-graph files during
>
> I barked up a similar tree in
> https://public-inbox.org/git/CACBZZX5SbYo5fVPtK6LW1FF96nR5591RHHC-5wdjW-fmg1R0EQ@mail.gmail.com/
>
> I wonder if you've seen that & what you think about that
> approach. I.e. have a core.version=2.28 (or core.version=+6) or whatever
> to opt-in to features we'd make default in 2.28. Would that be your
> core.featureAdoptionRate=6 (28-28 = 6)?
>
> I admit that question is partly rhetorical, because I think it suggests
> how hard it would be for users to reason about this.
>
> The "core.version" idea also sucks, but at least it's bound to our
> advertised version number, so it's obvious if you set it to e.g. +2 what
> feature track you're on, and furthermore when we'd commit to making that
> the default for users who don't set core.version (although we could of
> course always change our minds...). It's also something that mirrors how
> e.g. Perl, C compilers (with --std=*) treat this sort of thing.
>
> So I'm all for a facility to have a setting to collectively opt-in to
> new things early. But I think for such a thing we really should a) at
> least in principle commit to making those things the default eventually