List for cgit developers and users
 help / color / mirror / Atom feed
From: cgit at cryptocrack.de (Lukas Fleischer)
Subject: [RFC] Using Git's internal config system
Date: Wed, 5 Jun 2013 12:52:57 +0200	[thread overview]
Message-ID: <20130605105257.GA15273@blizzard> (raw)
In-Reply-To: <20130605102653.GR1072@serenity.lan>

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


  reply	other threads:[~2013-06-05 10:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-05 10:06 cgit
2013-06-05 10:18 ` mailings
2013-06-05 10:27   ` john
2013-06-05 10:26 ` john
2013-06-05 10:52   ` cgit [this message]
2013-06-05 11:15     ` john

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130605105257.GA15273@blizzard \
    --to=cgit@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).