Re: [RFC] Git config file reader in Perl (WIP)

From: Junio C Hamano <junkio@cox.net>
Date: Jan 20, 2007, 00:19 UTC
Message-ID: <7v8xfyczxi.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200701192344.11972.jnareb@gmail.com>

Jakub Narebski <jnareb@gmail.com> 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).