"Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > +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 > +`git gc`. I was re-reading the whole series, and found that the phrase "present significant benefits" was somewhat overselling. Wouldn't that claim largely depend on the end-user's workflow? The same comment applies to the description of "at least 5" level, too. I would not mind if we say "enabling this may present performance benefits", with or without "significant" before "performance benefits", and with or without ", depending how your repository is used" at the end. Thanks.
