git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>,
	Git Mailing List <git@vger.kernel.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Jeff King <peff@peff.net>, Junio C Hamano <gitster@pobox.com>,
	Derrick Stolee <dstolee@microsoft.com>
Subject: Re: [PATCH v2 1/3] repo-settings: create core.featureAdoptionRate setting
Date: Tue, 2 Jul 2019 18:09:41 +0700	[thread overview]
Message-ID: <CACsJy8Aqdb_-5ituTQMNjacHiJbw4abV=HsH9s6PoAGKyuwdJg@mail.gmail.com> (raw)
In-Reply-To: <87sgro7lxo.fsf@evledraar.gmail.com>

On Tue, Jul 2, 2019 at 5:47 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>
>
> 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

Some features may be best enabled for certain setups. This is why I
set configuration variables repo size, worktree size.. instead of just
one number.

> (if they don't suck) b) it needs to be obvious to the user how the
> "rate" relates to git releases.

I see this more like gcc =O options. And for those options, the
developers decide what to include. If you know what you want already,
you can just turn specific keys on. Otherwise you count on devs to do
the right things.

It would help if we have something like "gcc -Q -O2 --help=optimizers"
so you can see exactly what you need to turn on to achieve the same
thing. Then you can just set those have the same "per release"
settings.

Which makes me think about a slightly different implementation detail
(which I ignored because I didn't think further about per-release
stuff): since these are basically meta config to change defaults, we
can just implement them as a (builtin, or bundled) config file. The
user can see what are included much easier we have several different
config "profiles" (deep history, large worktree, bleeding-edge...) and
the user can include one or all [1].

[1] it also opens up the opportunity to have a standard (but optional)
set of aliases. But that's a touchy topic.
-- 
Duy

  reply	other threads:[~2019-07-02 11:10 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-03 20:18 [PATCH 00/11] [RFC] Create 'core.size=large' setting to update config defaults Derrick Stolee via GitGitGadget
2019-06-03 20:18 ` [PATCH 01/11] repo-settings: create repo.size=large setting Derrick Stolee via GitGitGadget
2019-06-03 20:42   ` Jeff Hostetler
2019-06-03 20:18 ` [PATCH 03/11] repo-settings: pack.useSparse=true Derrick Stolee via GitGitGadget
2019-06-03 20:18 ` [PATCH 02/11] repo-settings: use index.version=4 by default Derrick Stolee via GitGitGadget
2019-06-03 20:18 ` [PATCH 04/11] status: add status.aheadbehind setting Jeff Hostetler via GitGitGadget
2019-06-03 20:18 ` [PATCH 05/11] status: add warning when a/b calculation takes too long for long/normal format Jeff Hostetler via GitGitGadget
2019-06-03 20:18 ` [PATCH 06/11] status: ignore status.aheadbehind in porcelain formats Jeff Hostetler via GitGitGadget
2019-06-03 20:18 ` [PATCH 07/11] repo-settings: status.aheadBehind=false Derrick Stolee via GitGitGadget
2019-06-03 20:18 ` [PATCH 08/11] fetch: add --[no-]show-forced-updates argument Derrick Stolee via GitGitGadget
2019-06-03 20:18 ` [PATCH 09/11] fetch: warn about forced updates after branch list Derrick Stolee via GitGitGadget
2019-06-03 20:18 ` [PATCH 10/11] pull: add --[no-]show-forced-updates passthrough to fetch Derrick Stolee via GitGitGadget
2019-06-03 20:18 ` [PATCH 11/11] repo-settings: fetch.showForcedUpdates=false Derrick Stolee via GitGitGadget
2019-06-03 20:55 ` [PATCH 00/11] [RFC] Create 'core.size=large' setting to update config defaults Derrick Stolee
2019-06-04 14:43 ` Johannes Schindelin
2019-06-04 14:56   ` Derrick Stolee
2019-06-05 20:39 ` Junio C Hamano
2019-06-06 12:23   ` Derrick Stolee
2019-06-06 16:07     ` Junio C Hamano
2019-06-19 15:11 ` [PATCH v2 0/3] [RFC] Create 'core.featureAdoptionRate' " Derrick Stolee via GitGitGadget
2019-06-19 15:12   ` [PATCH v2 1/3] repo-settings: create core.featureAdoptionRate setting Derrick Stolee via GitGitGadget
2019-06-28 20:50     ` Junio C Hamano
2019-06-28 21:08       ` Derrick Stolee
2019-06-28 21:42     ` Junio C Hamano
2019-06-29  1:43       ` Derrick Stolee
2019-06-30 18:35         ` Carlo Arenas
2019-07-01 12:45           ` Derrick Stolee
2019-07-02 10:47     ` Ævar Arnfjörð Bjarmason
2019-07-02 11:09       ` Duy Nguyen [this message]
2019-07-02 14:54         ` Derrick Stolee
2019-07-02 16:59         ` Junio C Hamano
2019-06-19 15:12   ` [PATCH v2 2/3] repo-settings: use index.version=4 by default Derrick Stolee via GitGitGadget
2019-06-19 15:12   ` [PATCH v2 3/3] repo-settings: pack.useSparse=true Derrick Stolee via GitGitGadget
2019-07-01 14:29   ` [PATCH v3 0/3] [RFC] Create 'core.featureAdoptionRate' setting to update config defaults Derrick Stolee via GitGitGadget
2019-07-01 14:29     ` [PATCH v3 1/3] repo-settings: create core.featureAdoptionRate setting Derrick Stolee via GitGitGadget
2019-07-01 23:27       ` Carlo Arenas
2019-07-02  9:20       ` Duy Nguyen
2019-07-02 10:53         ` Ævar Arnfjörð Bjarmason
2019-07-04 22:47         ` Jakub Narebski
2019-07-01 14:29     ` [PATCH v3 2/3] repo-settings: use index.version=4 by default Derrick Stolee via GitGitGadget
2019-07-01 14:29     ` [PATCH v3 3/3] repo-settings: pack.useSparse=true Derrick Stolee via GitGitGadget
2019-07-08 19:22     ` [PATCH v3 0/3] [RFC] Create 'core.featureAdoptionRate' setting to update config defaults Derrick Stolee
2019-07-09 18:55       ` Taylor Blau
2019-07-09 19:21       ` Junio C Hamano
2019-07-09 19:45         ` Derrick Stolee
2019-07-09 22:05           ` Junio C Hamano
2019-07-22 12:10             ` Derrick Stolee
2019-07-11 21:54       ` Jakub Narebski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACsJy8Aqdb_-5ituTQMNjacHiJbw4abV=HsH9s6PoAGKyuwdJg@mail.gmail.com' \
    --to=pclouds@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=dstolee@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --subject='Re: [PATCH v2 1/3] repo-settings: create core.featureAdoptionRate setting' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).