[PATCH 0/2] Git-Config Parsing during scan-path

Jason A. Donenfeld Jason at zx2c4.com
Tue Oct 9 13:40:28 CEST 2012

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!


More information about the CGit mailing list