Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > You make an interesting point: values that start as a list of > independent booleans can grow dependencies over time. > > In retrospect, ISTM that a better interface for the indentation-related > "whitespace" settings would have been something like > > * "whitespace.indent" -- a single value chosen from "tabs-only | > spaces-only | tabs-when-possible | anything" > * "whitespace.tabwidth" -- an integer value > > This would have made the mutual-exclusivity of those choices manifest in > the style of configuration rather than hoping that the user notices that > his settings contradict each other. > > Let's dig into this example some more by imagining some other > hypothetical future extensions. Let's not; that line of thought entirely misses the point. If you start from one set of variables, you can define a structure (e.g. "there are indentation-related and you must choose only one among them") over it after the fact. Once you have chosen a structure, you have to live with it. Either you make sure that a structure itself is extensible, or you make sure you accept a new variable only if it fits within a structure. Either way, you lose. You cannot predict the future, and you do not want to constrain those who will contribute to the project in the future. My aversion to one-variable-per-knob was primarily against the "because that is how the variables are internally represented; a collection of enums that can be independently set" argument. If we assume that one-variable-per-knob style implies variables that can be independently set, that _is_ defining the structure the future work has to live within. But as I and Peff discussed in the other sub(sub)thread, having two variables placed flatly in the namespace, e.g. ws.indentWithTab and ws.noTabInIndent, does not have to mean they are independent. And the opposite is also true; having these two knobs as possible elements of the value of a single variable does not imply they always have meaningful interactions. So I am fine with "fsck.missingTagger = ignore/warn/error", as long as the argument that supports the style is not "because fsck.missingTagger and fsck.malformedIdent are independent". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html