Re: git silently ignores include directive with single quotes

[Junio C Hamano <gitster@pobox.com>]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Updated proposal:
>
>   1. Treat strings starting or ending with single-quote as worth
>      quoting in config.c::write_pair (line 3269).  This would already
>      help with the original issue, since the config would say
>
> 	[foo]
> 		bar = "'baz'"
>
>      allowing a quick diagnosis.

This does not change anything essential from Git's point of view
since the previous round.

But I changed my mind anyway ;-)  Earlier I said "if we do not
intend to make sq special, we shouldn't do #1", and it still is a
good direction to go.

But making sq special does not have to be making sq a character that
quotes.  A character (or a character sequence) that is *not* quoting
can still be special---for example, we can say certain character or
a character sequence *must* be quoted, and make sq such a character.

That is, even if we stop at your step 3. or step 2., and did not go
to step 4. (which I think is a bad idea for little gain), we are
already treating sq as a special character, and step 1. above is a
reasonable way to start the transition to that better world.

The reason why it is a better world that have "must be quoted, even
though they are not quoting characters themselves" is solely because
that would avoid confusion for those who are not familiar with the
file format, even when we stop at step #2.  In addition to a single
quote a the beginning of the value, I think two or more SP deserve
to be such a "must be quoted" sequence, i.e. instead of producing
this result, which we see with today's Git:

	$ git config a.test0 "'foo"
	$ git config a.test1 "foo  bar" ;# two spaces
	$ grep -A2 '\[a\]' config
	[a]
		test0 = 'foo
		test1 = foo  bar

we'd produce

	$ grep -A2 '\[a\]' config
	[a]
		test0 = "'foo"
		test1 = "foo  bar"

but we can still interpret what we have historically written the
same way.

I do not know if step #3 is a good idea, and I do not think step #2
is particularly a good stopping point.  Step #1 is probably slightly
a better stopping point if the aim is to avoid user confusion than
step #2.


>   2. (optional) Warn if a value is surrounded in single-quotes,
>      encouraging using surrounding double-quotes to disambiguate.
>
>   3. (optional) Error out if a value is surrounded in single-quotes,
>      encouraging replacing with or surrounding with double-quote,
>      depending on the user's intention.
>
>   4. (optional) Start treating wrapping single-quotes specially
>      somehow.
>
> As before, I think step 1 is a good idea, but I'm not convinced about
> any of the later steps.
>
> Thanks,
> Jonathan