From mboxrd@z Thu Jan 1 00:00:00 1970 From: john at keeping.me.uk (John Keeping) Date: Wed, 5 Jun 2013 11:26:53 +0100 Subject: [RFC] Using Git's internal config system In-Reply-To: <20130605100658.GA20440@blizzard> References: <20130605100658.GA20440@blizzard> Message-ID: <20130605102653.GR1072@serenity.lan> On Wed, Jun 05, 2013 at 12:06:58PM +0200, Lukas Fleischer wrote: > We have been discussing the feasibility of using Git's internal config > system instead of our own configuration file parser on IRC and on the > mailing list. It seems that this is doable -- however, creating a sane > upgrade path is not that easy. > > What cgit config files currently look like: > > cache-size=1000 > enable-index-links=1 > > repo.url=repo1.git > repo.path=/path/to/repo1.git/ > repo.desc=Repository 1 > > repo.url=repo2.git > repo.path=/path/to/repo2.git/ > repo.desc=Repository 2 > > What cgit config files might look like when using Git's internal config > system: > > [core] > cache-size = 1000 > enable-index-links = 1 > [repo "repo1"] > url = repo1.git > path = /path/to/repo1.git/ > desc = Repository 1 > [repo "repo2"] > url = repo2.git > path = /path/to/repo2.git/ > desc = Repository 2 > > I was thinking of a way to support both syntaxes so that people have > enough time to migrate to the new format (the other possibility is just > switching to the new format without providing any backwards > compatibility). Since Git's config system does not allow dots inside > variable names, I suggest following implementation: > > 1. Use strbuf instead of fixed-size buffers to read lines from the > configuration file (I already submitted a patch for this). How about dropping into the new syntax as soon as you hit a line beginning with "["? So we start off using the existing parser, and if you hit "[" feed the rest of the file to Git's parser. > 2. Allow following syntax which allows for creating subsections for each > repository instead of using "repo.url" as a delimiter: > > repo.repo1.url=repo1.git > repo.repo1.path=/path/to/repo1.git/ > repo.repo1.desc=Repository 1 > > 3. Support sections and internally map each configuration variable "var" > that is specified inside section "section" to "var.section" and each > "var" that is specified inside section 'repo "reponame"' to > "repo.reponame.var", respectively (that is exactly how Git does it > internally). Prefix section-less configuration variables with "core." > > 4. Deprecate the old configuration format. > > 5. Drop support for the old configuration format, remove legacy code and > use Git's internal config system instead in a future major release. > > I prepared patches for 2 and 3. However, there are several issues with > the new syntax: > > * We can no longer use "mimetype." in the core section. Solution is > simple: Create a separate "mimetype" section. > > * We need to find an alternate syntax for "repo.module-link.name = > value". As far as I know, Git does not support nested sections. Does > anybody have an idea how to do this? We need something like: > > [repo "foo"] > url = foo.git > path = /some/path/to/foo/ > desc = Foo repository > [module-link "path1"] > format = formatstring1 > [module-link "path2"] > format = formatstring2 > > Maybe just use "module-link = " and allow delimiters to specify pairs > of paths and corresponding format strings? > > * How do we support "section = " statements? Basically the same issue. We could just support that using ordering like we currently do. So when you hit a "section.name" entry we switch section. Since Git's parser just uses callbacks that should be fairly easy to implement. However, I'm not sure that Git's config syntax necessarily maps well to CGit's needs. Git only supports three levels of hierarchy, so the obvious mapping of several features does not work. Already some config keys are not available with "enable-git-config = 1" because the key would be a path but Git only accepts that in a section name.