On Thu, Feb 23, 2017 at 10:08:57PM -0800, Junio C Hamano wrote:
> Anyway, here is an updated one (the part of the patch to t/ is not
> shown as it is unchanged).
>
> -- >8 --
> Subject: [PATCH] config: use git_config_parse_key() in
> git_config_parse_parameter()
Looks good. Nice and simple.
-P
Jeff King writes:
>> 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,
On Thu, Feb 23, 2017 at 08:17:44PM -0800, Junio C Hamano wrote:
> > 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
Jeff King 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 suspec
On Thu, Feb 23, 2017 at 03:19:58PM -0800, Junio C Hamano wrote:
> > But you are right. config-parse-key does have the simpler string
> > that can just be given to the canonicalize thing and we should be
> > able to reuse it.
>
> Actually, I think we can just use the existing config_parse_key()
>
Junio C Hamano writes:
> Jeff King writes:
>
>> FWIW, the code looks OK here. It is a shame to duplicate the policy
>> found in git_config_parse_key(), though.
>>
>> I wonder if we could make a master version of that which canonicalizes
>> in-place, and then just wrap it for the git_config_parse
Jeff King writes:
> FWIW, the code looks OK here. It is a shame to duplicate the policy
> found in git_config_parse_key(), though.
>
> I wonder if we could make a master version of that which canonicalizes
> in-place, and then just wrap it for the git_config_parse_key()
> interface. Actually, I g
On Tue, Feb 21, 2017 at 01:24:38PM -0800, Junio C Hamano wrote:
> The parsing of one-shot assignments of configuration variables that
> come from the command line historically was quite loose and allowed
> anything to pass.
>
> The configuration variable names that come from files are validated
>
Junio C Hamano writes:
> /* find the last dot (we start from the first dot we just found) */
> - for (last_dot = cp; *cp; cp++)
> + for (; *cp; cp++)
> if (*cp == '.')
> last_dot = cp;
This line probably needs this fix-up on top.
-- >8 --
Subjec
The parsing of one-shot assignments of configuration variables that
come from the command line historically was quite loose and allowed
anything to pass.
The configuration variable names that come from files are validated
in git_config_parse_source(), which uses get_base_var() that grabs
the (and
10 matches
Mail list logo
