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:06:58 +0200	[thread overview]
Message-ID: <20130605100658.GA20440@blizzard> (raw)

Hi,

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

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.

Ideas and suggestions welcome!

Regards,
Lukas


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

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-05 10:06 cgit [this message]
2013-06-05 10:18 ` mailings
2013-06-05 10:27   ` john
2013-06-05 10:26 ` john
2013-06-05 10:52   ` cgit
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=20130605100658.GA20440@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).