List for cgit developers and users
 help / color / mirror / Atom feed
From: Jason at zx2c4.com (Jason A. Donenfeld)
Subject: [PATCH 0/2] Git-Config Parsing during scan-path
Date: Tue, 9 Oct 2012 13:40:28 +0200	[thread overview]
Message-ID: <CAHmME9rVsbZ_3Y-2Qm-a16Lcr9pvs4pwiMxufJLz+p0QkJKg6w@mail.gmail.com> (raw)
In-Reply-To: <5073EEB9.9090704@necoro.eu>

On Tue, Oct 9, 2012 at 11:30 AM, Ren? Neumann <lists at necoro.eu> wrote:
> That's true. My original intention was: Use the gitweb stuff 90% of the
> time -- and the cgit ones if there is no appropriate gitweb equivalent.
> Gitweb only has three useful keys -- and those are already mapped.
> One other might be "gitweb.snaphot" to be mapped to "repo.snapshots".
>
> But anything else (like repo.defbranch) cannot be set with the current
> mechanisms. Currently people are using git-hooks to generate cgitrc and
> stuff -- which to me personally feels more like hacking then real
> support :).


I am sort of leaning toward this -- just adding gitweb.defbranch, and
calling it a day.

> Well -- sticking with the gitweb namespace alone has the same
> consequences I mentioned above: Either we stick with the already defined
> keys there -- thereby limiting what can easily be configured. Or we add
> new keys to it which might lead to problems in the future. Also there
> might be keys in gitweb, that have slightly different semantics or
> namings from the counterparts in cgit (see for instance 'snapshot' vs
> 'snapshots').

Yea, you might be right. So let's say we do two namespaces, and it
looks like this:

gitweb.description -->
gitweb.category --> section
gitweb.owner -->
gitweb.defbranch -->

And we put these under a setting "gitweb gitconfig".

And then:

cgit.* -->

And this goes under a different setting "cgit gitconfig".



Alternatively, we just have one option, "use gitconfig settings", that maps:

gitweb.description -->
gitweb.category --> section
gitweb.owner -->
cgit.* -->


Which of these alternatives do you like better?




> I don't oppose removing most of it. I think the remark to set gitconfig
> values (plus perhaps a link to the appropriate gitolite doc) is
> self-explanatory. Also, if it hits 'master', I would send a
> documentation patch to gitolite, adding a cgit section to their
> 'External Tools' page.

Don't forget, also, about the cgit wiki!

http://git.zx2c4.com/cgit/about/
http://git.zx2c4.com/cgit/about/faq
http://git.zx2c4.com/cgit/tree/?h=wiki




  reply	other threads:[~2012-10-09 11:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-07 21:23 
2012-10-07 21:23 ` [PATCH 1/2] Read "cgit.*" settings from gitconfig 
2012-10-08 15:14   ` jamie.couture
2012-10-08 15:19     ` Jason
2012-10-08 15:24       ` 
2012-10-08 15:25         ` Jason
2012-10-07 21:23 ` [PATCH 2/2] Documentation for the gitconfig sourcing 
2012-10-08 21:27 ` [PATCH 0/2] Git-Config Parsing during scan-path Jason
2012-10-09  9:30   ` 
2012-10-09 11:40     ` Jason [this message]
2012-10-09 12:07       ` 
2012-10-09 12:22         ` Jason
2012-10-09 11:02   ` jamie.couture

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=CAHmME9rVsbZ_3Y-2Qm-a16Lcr9pvs4pwiMxufJLz+p0QkJKg6w@mail.gmail.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).