List for cgit developers and users
 help / color / mirror / Atom feed
From: mailings at hupie.com (Ferry Huberts)
Subject: [RFC] Using Git's internal config system
Date: Wed, 05 Jun 2013 12:18:35 +0200	[thread overview]
Message-ID: <51AF107B.8040003@hupie.com> (raw)
In-Reply-To: <20130605100658.GA20440@blizzard>



On 05/06/13 12:06, Lukas Fleischer wrote:
> 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
> 

How about just adding the cgit repo specific config to the actual git
repo config file?
Something like:

[cgit]
url = foo.git
path = /some/path/to/foo/
desc = Foo repository

section = ....

[cgit "module-links"]
format = formatstring1
format = formatstring2

etc..


>   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
> _______________________________________________
> CGit mailing list
> CGit at lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/cgit
> 

-- 
Ferry Huberts


  reply	other threads:[~2013-06-05 10:18 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 [this message]
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=51AF107B.8040003@hupie.com \
    --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).