Jonathan Nieder <jrnieder@xxxxxxxxx> 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
