Jeff King <p...@peff.net> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html