Derrick Stolee <stolee@xxxxxxxxx> writes: > On 7/1/2019 10:29 AM, Derrick Stolee via GitGitGadget wrote: >> >> Here is a second run at this RFC, which aims to create a "meta" config >> setting that automatically turns on other settings according to a user's >> willingness to trade new Git behavior or new feature risk for performance >> benefits. The new name for the setting is "core.featureAdoptionRate" and is >> an integer scale from 0 to 10. There will be multiple "categories" of >> settings, and the intention is to allow more granular levels as necessary. > > (Adding people who contributed feedback to CC line.) > > It seems that this "Feature Adoption Rate" idea was too simplistic, and > had several issues. Time to take a different stab at this direction, but > with these clear goals in mind: > > 1. We want intermediate users to be able to take advantage of new config > options without watching every release for new config options. > > 2. The config name should match the general effect of the implied > settings. > > 3. There are orthogonal settings that may not apply beneficially to > all repos. > > With this in mind, I propose instead a set of "feature.*" config settings > that form groups of "community recommended" settings (with some caveats). > In the space below, I'll list a set of possible feature names and the > implied config options. A bit of bikeshed painting: I am unsure if "feature.*" is the best name for this category of config (meta)settings. Perhaps "defaults.*" or "presets.*" would be a better name -- they would certainly be more indicative of what setting this config variable actually *does*. > First, the main two categories we've discussed so far: many commits and > many files. These two feature sets are for when your repo is large in > one of these dimensions. Perhaps there are other settings to include > in these? > > feature.manyFiles: > index.version = 4 > index.threads = true > core.untrackedCache = true > > feature.manyCommits: > core.commitGraph = true > gc.writeCommitGraph = true > (future: fetch.writeSplitCommitGraph = true) > > Note: the `fetch.writeSplitCommitGraph` does not exist yet, but could > be introduced in a later release to write a new commit-graph (with --split) > on fetch. That looks really nice (for a built-in set of defaults). It would be good if the above format, or something like it, could be used as a source of truth for this feature. > 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 Well... turning off by default status.aheadBehind and fetch.showForcedUpdates makes sense only if also repository is large. Otherwise it is not useful, and even a bad thing. Both of status.aheadBehind and fetch.showForcedUpdates are discoverable; as far as I remember Git would show a hint about those config options when the related task takes too long (either 'git status' in case of status.aheadBehind, or 'git fetch' in the latter case). I don't know if we have discoverability in the opposite direction: do we show some advice (which as all advice can be turned off in the config) if either of status.aheadBehind or fetch.showForcedUpdates is false? > We have not discussed anything like the next category, but Dscho thought > a set of configs to make pretty diffs could be a fun "meta-config" setting: > > feature.prettyDiff: > diff.color = auto > ui.color = auto > diff.context = 5 > diff.colorMoved = true > diff.colorMovedWs = allow-indentation-change > diff.algorithm = minimal > > These are just a first round of suggestions. I'm sure we would enjoy a > debate around an optimal set of diff settings. Maybe Git for Windows defaults would be shipped in similar form; though I wonder if in this case it is better from simple system-wide settings. > Finally, here is a kind of feature that I could imagine being helpful > in the future, but maybe is not a good idea to pursue right now. In > some cases users use "gc.auto = 0" to prevent all user-time blocking > maintenance. Don't we have a hook for that? > This can degrade performance over time as loose objects > and pack-files accumulate. The performance could mostly be recovered > by using a multi-pack-index, but there is not current way to automatically > write the file. This would not solve the space issues that happen here. > > feature.noGC: > gc.auto = 0 > core.multiPackIndex = true > (future: fetch.writeMultiPackIndex = true) > > What do people think about this general idea? Are there any other > feature.* settings that could be useful? Any additional settings > to add to these groups? Maybe feature.slowFilesystem / defaults.slowFilesystem? Or maybe feature.server? Best regards, -- Jakub Narębski
