From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Tue, 9 Oct 2012 13:40:28 +0200 Subject: [PATCH 0/2] Git-Config Parsing during scan-path In-Reply-To: <5073EEB9.9090704@necoro.eu> References: <1349645027-22007-1-git-send-email-necoro@necoro.net> <5073EEB9.9090704@necoro.eu> Message-ID: On Tue, Oct 9, 2012 at 11:30 AM, Ren? Neumann 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