Jeff King <peff@xxxxxxxx> writes: > 1. I chose the value-less boolean as a token to reset the list (since > it is otherwise an unmeaningful error). The example above shows its > use with "-c", but you could also do: > > [credential] > helper > helper = foo > > in a config file itself. This is probably rather unintuitive. For this one, and I suspect all the "multi-valued" ones, I think it actually is the most sensible syntax (another possiblity is to give an empty string, assuming that all multi-valued variables we care about take non-empty string or numeric values), as I do not see a useful/valid use case for wanting to define boolean multi-valued variable. > If we can accept stomping on an unlikely-used token, something > like: > > git -c credential.helper=RESET fetch ... > > is more sensible (and we can argue about the exact token used). This unfortunately is unlikely to fly well if we are shooting for a generic mechanism that is applicable for multi-valued ones in general (your comment 2. below is very much relevant and true). > If we can accept new syntax and new config code, something like: > > git -c '!credential.helper' fetch ... > > is probably workable. I think I suggested exactly this syntax (and "[credential] !helper" in the config file) when this was brought up the last time, but it was shot down because that would make the resulting configuration file unparsable (not just ignored) by existing versions of Git. But perhaps it is a good thing to break existing parser when "clear the variable settings seen so far" is used. It would not do us very good to allow existing implementations to ignore it and continue as if all other entries (and special token like RESET) matter will silently give users incorrect result. -- 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