Derrick Stolee <stolee@xxxxxxxxx> 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. 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.
