git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"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>,
	"Derrick Stolee" <dstolee@microsoft.com>
Subject: Re: [PATCH v2 1/3] repo-settings: create core.featureAdoptionRate setting
Date: Tue, 02 Jul 2019 09:59:20 -0700	[thread overview]
Message-ID: <xmqqv9wk4bkn.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <CACsJy8Aqdb_-5ituTQMNjacHiJbw4abV=HsH9s6PoAGKyuwdJg@mail.gmail.com> (Duy Nguyen's message of "Tue, 2 Jul 2019 18:09:41 +0700")

Duy Nguyen <pclouds@gmail.com> writes:

>> 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.

Yeah, I think the concept of core.fetureAdoptionRate is faulty at
multiple counts, and I admit I am guilty of making at least one
aspect worse by giving the topic branch to queue these patches a
mistaken name of "early-adoption".

Some tweaks, like the use of index version 4, may be something we
strive to make it eventually suitable for _all_ users.  

The effort may involve multiple iterations of things like "gee, the
prefix-compression works very well for really big tree, but sucks
for a project of medium size; lets tweak to automatically
enable/disable it based on the size of the tree", but the main point
is that we want to eventually make it good for projects of all sizes
and different access patterns.  While we do the treaking, the user
experience may be rocky, and "early adoption" model is perfectly
suitable for a thing like this.

But some other tweaks, like the ahead-behind thing, are what we
would never make it the default for everybody.  They are "Git is
never designed to be used like this, but if we disable small things
like this and that, the end user experience for those who used to
have them might suffer, but other aspect of the system becomes
usable" tradeoffs.  When we are done experimenting and know what
kind of system castration may give acceptable trade off, we know the
subset of users to whom these tweaks give benefit (and others to whom
these are not improvements).  Opting into these things is not about
"early adoption".

Also as raised in another message in this thread, I do agree that
the configuration does not belong to the "core." hierarchy.  It is
more like a macro, that flips individual configuration based on a
higher level "grouping" (e.g. my project falls into "large but
infrequently updated" category) to suit the access pattern.

> 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.

Yup.  Sorry for backing a wrong model.  And I kind of like the word
"bundled" you mention below, not as in "bundled with Git", but more
as in "these configuration settings are bundled together to serve
users of this kind of project".

> 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.

  parent reply	other threads:[~2019-07-02 16:59 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 02/11] repo-settings: use index.version=4 by default Derrick Stolee via GitGitGadget
2019-06-03 20:18 ` [PATCH 03/11] repo-settings: pack.useSparse=true 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 07/11] repo-settings: status.aheadBehind=false Derrick Stolee 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 08/11] fetch: add --[no-]show-forced-updates argument 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 09/11] fetch: warn about forced updates after branch list 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
2019-07-02 14:54         ` Derrick Stolee
2019-07-02 16:59         ` Junio C Hamano [this message]
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=xmqqv9wk4bkn.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=dstolee@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=pclouds@gmail.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).