Re: git silently ignores include directive with single quotes

[Jonathan Nieder]

Hi,

Junio C Hamano wrote:
> Jeff King <p...@peff.net> writes:

>> So I think it's been covered elsewhere that single quotes aren't a thing
>> in git's config format. I will say that this was actually a minor
>> surprise to me, after a decade of working with the format. ;)
>>
>> I don't know if it's worth changing now or not It would be
>> backwards-incompatible, but I wonder if we could do it in a sane way.
>> E.g., with a rule like:
>>
>>   - if the first non-whitespace character of the value is a
>>     single-quote, assume the value is quoted and apply normal shell
>>     rules (i.e., no backslash escapes until the ending single-quote)
>>
>>   - otherwise, single-quotes are not special at all
>
> At least the rule would not force those with ' in the middle of
> their family names to surround the user.name with extra double
> quotes, and it would probably be a good and safe practical solution.
> Being safe "by magic" tend to become hard to explain, but in this
> case the magic part is probably still simple enough.

Given that today,

        git config foo.bar "'baz'"

produces

        [foo]
                bar = 'baz'

I don't think this would be safe to do.  Since the underlying problem
is that the latter syntax is confusing, I wonder if we can do the
following:

 1. Treat single-quote as worth quoting in config.c::write_pair (line
    2516).  This would already help with the original issue, since the
    config would say

        [foo]
                bar = \'baz\'

    allowing a quick diagnosis.

 2. (optional) Warn if a value is surrounded in single-quotes,
    encouraging using backslash to disambiguate.

 3. (optional) Error out if a value is surrounded in single-quotes,
    encouraging using double-quote or backslash, depending on the
    user's intention.

 4. (optional) Start treating wrapping single-quotes specially
    somehow.

I think step 1 is a good idea, but I'm not convinced about any of the
later steps.

I also agree with the comments upthread about wanting a way to do a
'[include] path' that errors out if the file doesn't exist, and maybe
even starting a transition to repurpose standard [include] path to do
that.

Thanks,
Jonathan