[RFC] Using Git's internal config system

Lukas Fleischer cgit at cryptocrack.de
Wed Jun 5 12:52:57 CEST 2013


On Wed, Jun 05, 2013 at 11:26:53AM +0100, John Keeping wrote:
> On Wed, Jun 05, 2013 at 12:06:58PM +0200, Lukas Fleischer wrote:
> [...]
> > 
> > * 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.

Unfortunately, it is not that simple. With the new syntax, elements of
the same section are grouped together and we can't put elements from
different sections in arbitrary order, unless we want to do something
like:

    [core]
        section = section1
    [repo "repo1"]
        url = repo1.git
        path = /path/to/repo1/
    [core]
        section = section2
    [repo "repo2"]
        url = repo2.git
        path = /path/to/repo2/

What we could do is add a "section" key to each repository.

> 
> 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.

I tend to agree. Jason, any comments?

I will rework that patch I already submitted for now. Using Git's config
system (if desirable) seems to require a lot of preparatory work...


More information about the CGit mailing list