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
next prev parent 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).