Jeff King <peff@xxxxxxxx> writes: I didn't reply to the latter part of this message yesterday, because I wanted to think more on it. > But is it such a bad thing to have them in conflict? Can't we define a > set of rules that does what people expects? For example, by the "last > one wins" principle, any time we see "whitespace.tab-in-indent", it > clears the setting of "whitespace.indent-with-non-tab", and vice versa. > This isn't represented syntactically in the config file, ... I agree. Both one-variable-per-knob and value-with-list-of-knobs do not express the semantic linkage between knobs; once we convince the users that one-variable-per-knob format does not mean they represent independent and orthgonal settings, the issue becomes a trade-off between * Is it concise to let end users skim through? * Is it easy to parse by scripters? > By the way, this is the exact case I am concerned about for fsck.*. Our > use case at GitHub would be something like: > > a. We set up sane defaults for fsck.* in /etc/gitconfig > > b. User complains that we will not accept their push, which contains > objects with malformed committers. > > c. Support investigates, determines that the malformed objects are > part of a well-established history, and that they are OK to enter. > > d. We relax fsck.committerIdent in that repo's $GIT_DIR/config file. > > Copy-and-pasting the rest of the rules from (a) into the repo config > file in step (d) is not ideal. It probably can be worked around by the later-one-wins rule per item, e.g. after seeing "fsck.ignore = A B C" in /etc/gitconfig and then seeing "fsck.error = B" in $GIT_DIR/config, the latter will flip the three-way radio button for B from ignore to error (the other possible setting of the radio button is 'warn'), while leaving the three-way radio buttons for A and C set to ignore. We can (and have to) do the same with "fsck.B = ignore" in /etc/gitconfig that gets overridden by "fsck.B = error" in $GIT_DIR/config, and that comes _free_, which makes it an attractive proposition. As I already said, I am fine with "fsck.missingTagger = ignore". -- 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