Jeff King <peff@xxxxxxxx> writes: > This is technically a backwards incompatibility, but I'd consider it a > simple bugfix. The existing behavior was unintentional, made no sense, > and was never documented. Yeah, I tend to agree. I actually would not shed any tears if the breakage were that it was impossible to pass "NULL is true" boolean via "git -c" interface, but it is the other way around. It is much more grave a problem that we cannot pass an empty string as a value, and we should fix it. > Looking over strbuf_split's interface, I think it's rather > counter-intuitive, and I was tempted to change it. But there are several > other callers that rely on it, and the chance for introducing a subtle > bug is high. This is the least invasive fix (and it really is not any > less readable than what was already there :) ). ;-) > +# We just need a type-specifier here that cares about the > +# distinction internally between a NULL boolean and a real > +# string (because most of git's internal parsers do care). > +# Using "--path" works, but we do not otherwise care about > +# its semantics. > +test_expect_success 'git -c can represent empty string' ' > + echo >expect && > + git -c foo.empty= config --path foo.empty >actual && > + test_cmp expect actual > +' Another way may be "git config -l" and see if we see a = on the entry for foo.empty, but I think the way you did this is nicer. > test_expect_success 'key sanity-checking' ' > test_must_fail git config foo=bar && > test_must_fail git config foo=.bar && -- 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