Jeff King <[email protected]> writes:
>> pair = strbuf_split_str(text, '=', 2);
>> if (!pair[0])
>
> Hmm. I suspect one cannot do:
>
> git -c 'section.subsection with an = in it.key=foo' ...
>
> Definitely not a new problem, nor something that should block your
> patch. But if we want to fix it, I suspect the problem will ultimately
> involve parsing left-to-right to get the key first, then confirming it
> has an =, and then the value.
Backtracking will not fundamentally "fix" parsing of
a.b=c=.d
between twhse two
[a "b="] c = ".d"
[a] b = "c=.d"
unfortunately, I think. I do not think it is worth doing the "best
effort" with erroring out when ambiguous, because there is no way
for the end user to disambiguate, unless we introduce a different
syntax, at which point we cannot use config_parse_key() anymore.
>> + if (git_config_parse_key(pair[0]->buf, &canonical_name, NULL))
>> return -1;
>> - }
>
> I think git_config_parse_key() will free canonical_name itself if it
> returns failure. But do you need to strbuf_list_free(pair) here?
Yeah, I missed that one. Thanks.
