git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Derrick Stolee <stolee@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Johannes.Schindelin@gmx.de, peff@peff.net,
	"Jakub Narębski" <jnareb@gmail.com>,
	"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
	"Carlo Marcelo Arenas Belón" <carenas@gmail.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH v3 0/3] [RFC] Create 'core.featureAdoptionRate' setting to update config defaults
Date: Tue, 9 Jul 2019 15:45:40 -0400	[thread overview]
Message-ID: <afdaaa93-8769-c859-e957-e61d27b6d5a9@gmail.com> (raw)
In-Reply-To: <xmqqo923ui7x.fsf@gitster-ct.c.googlers.com>

On 7/9/2019 3:21 PM, Junio C Hamano wrote:
> Derrick Stolee <stolee@gmail.com> writes:
> 
>> The other category that has been discussed already is that of "experimental
>> features that we generally think are helpful but change behavior slightly in
>> some cases".
>>
>> 	feature.experimental:
>> 		pack.useSparse = true
>> 		status.aheadBehind = false
>> 		fetch.showForcedUpdates = false
>> 		merge.directoryRenames = true
>> 		protocol.version = 2
>> 		fetch.negotiationAlgorithm = skipping
> 
> Other classes you listed I can easily support, but I have trouble
> deciding if this concept itself is bad, or merely that some/many of
> the sample knobs you listed above are not exactly appropriate.
> Either way, I have hard time swallowing this one as-is.  You may
> think aheadBehind==false is helpful, but I don't, for example, and
> there may be people for and against each of the experimental knobs.

Thanks for the specific note about aheadBehind. I'll drop that one
from consideration.

I suppose that fetch.showForcedUpdates is in the same category, and
it has a self-discovery mechanism (a warning message) for users who
feel the pain of checking for forced updates (i.e. it takes >10s).

> But there may be a clear set of "this is agreed to be the way to the
> future, but the implementation currently is too convoluted and
> suspected of bugs, so we'll let early adoptors opt into the feature,
> and when that happens, eventually this knob will go away (i.e. you
> won't be able to turn it off)" type of knobs.  Or it may change the
> behaviour drastically, but as long as it is agreed that the future
> lies in that direction, I think it is OK to throw such a knob into
> this class.  The key points are (1) we are committed that in the
> future everybody will be forced to have it and (2) it is not merely
> "we generally think", but "the decision about the future has been
> made---there won't be any other way".  The feature.experimental
> becomes merely a way to let early adoptors in.  If you limit the
> individual features governed by feature.experimental to that kind of
> knobs, I can be easily convinced that this class is a good idea.

From this list, do you think any of these settings are likely to
become defaults? It seems that protocol.version = 2 may be a default
now that _most_ services have an implementation, and it always falls
back to protocol v1 without extra cost.

When pack.useSparse was first introduced, I considered making it true
by default after a while. But you protested, saying you want people
knocking at the door saying it is useful. What if it lived here?

fetch.negotiationAlgorithm and merge.directoryRenames seem like
valuable features and maybe just need more time out in the world
before they could be considered defaults.

I appreciate all of the feedback, and to drive the discussion forward
I'm trying to tease out very specific opinions.

Thanks,
-Stolee

  reply	other threads:[~2019-07-09 19:45 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' " 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 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
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 [this message]
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=afdaaa93-8769-c859-e957-e61d27b6d5a9@gmail.com \
    --to=stolee@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=carenas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=jnareb@gmail.com \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    --subject='Re: [PATCH v3 0/3] [RFC] Create '\''core.featureAdoptionRate'\'' setting to update config defaults' \
    /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).