Jakub Narebski <jnareb@xxxxxxxxx> writes:
> I'm not sure how to tell that you can have [section] if you have
> [section "subsection"], but you don't need to.
s/I'm not .*that//; would be enough, I think.
> And I'm not sure if some behavior should not be changed, for example
> allowing _any_ line to be continued with `\`, or that other character
> escape sequences and perhaps also octal character sequences should be
> allowed (either that or `\b` should not be parsed).
I do not think we need continuation line for [] headers, if that
is what you mean. I offhand do not think anybody would scream
if we start parsing full c-quote.
One thing that left me puzzled after reading the description was
what a user can do with "subsection". It is unclear from the
description if [section "sub.section"], [section"sub.sec=ti.on"]
or worse yet, [section "sub\nsection with an embbedded LF"] are
allowed. The rest seemed sane.
I think the current repo-config handles sane cases alright, but
it is still fragile in error cases. For example:
$ git repo-config 'foo.bar=bzz
baz.boo' foobar
does not currently barf, but results in a corrupted config file.
$ git repo-config 'foo.bar=bzz
baz.boo'
fatal: bad config file line 56 in .git/config
$ sed -ne '55,$p' .git/config
[foo "bar=bzz
baz"]
boo = foobar
The only way we use the subsection names for (almost arbitrary)
end user string is to store branch names, so LF is not an issue
and we could forbid it (if need arises loosening the restriction
while updating the code to behave sanely is easier than leaving
it open without properly checking).
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html