On 7/2/2019 7:09 AM, Duy Nguyen wrote: > On Tue, Jul 2, 2019 at 5:47 PM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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@xxxxxxxxxxxxxx/ >> >> 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 had not seen that message. Thanks for the link. However, I don't think that your idea of "give me features that will be default soon" is enough, as some of these features will _never_ be turned on by default. It's more about how much a user is willing to have some slight changes (i.e. extra files during maintenance [commit-graph], different index format, changed ahead/behind messages in status) in exchange for an overall "better" experience. Here "better" is decided by the community members adjusting the values on this feature. >> I admit that question is partly rhetorical, because I think it suggests >> how hard it would be for users to reason about this. The intention here is to make this as simple for users as possible. I want to be able to say "I highly recommend you set core.featureAdoptionRate=5" and for them to not need to know what is happening. Of course, they can learn more about the details and opt-out as things change. >> 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. You are right that some features are best for different scale factors: * commit-graph is best with a deep history. * index version 4 is best with a large working directory. These things are usually correlated, and users don't always know what exactly is "large" for any of these variables. Further, these features actually don't have much downside even if a user is legitimately struggling with one of these scale factors and not another. >> (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]. In some sense, this is creating a list of growing config profiles that each include the previous one: config-3 (core.commitGraph, gc.writeCommitGraph, index.version) config-5 (config-3 + pack.useSparse) config-7 (config-5 + status.aheadBehind, fetch.showForcedUpdates) The issue you seem to have is that we are not creating multiple dimensions of options. I think simplicity is key here. Anyone with the knowledge to deeply understand multiple dimensions can just assign the config options as they see fit. This is _not_ a feature for power users. > [1] it also opens up the opportunity to have a standard (but optional) > set of aliases. But that's a touchy topic. Standard aliases is an interesting topic, but tangential to the topic at hand and I'd prefer to leave it out of the current discussion. -Stolee
