Jeff King <> 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 &&
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to