Hi,
Junio C Hamano wrote:
> Jeff King <peff@xxxxxxxx> 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
