Jeff King <peff@xxxxxxxx> 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.