From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 24 Feb 2017 04:17:44 GMT
Subject: Re: [PATCH v2] config: reject invalid VAR in 'git -c VAR=VAL command'
Message-ID: <xmqqh93k5ijb.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170224004105.ayddcwlnpmq7tifu@sigill.intra.peff.net>

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