From mboxrd@z Thu Jan 1 00:00:00 1970 From: lists at necoro.eu (=?UTF-8?B?UmVuw6kgTmV1bWFubg==?=) Date: Tue, 09 Oct 2012 11:30:33 +0200 Subject: [PATCH 0/2] Git-Config Parsing during scan-path In-Reply-To: References: <1349645027-22007-1-git-send-email-necoro@necoro.net> Message-ID: <5073EEB9.9090704@necoro.eu> Hi Jason, > I've merged these changes into a branch in the repo: > http://git.zx2c4.com/cgit/log/?h=rn/gitconfig Thanks. > - Currently the section and description tags are taken care of using > gitweb.category and gitweb.description, just fine using these two > commits in master: > http://git.zx2c4.com/cgit/commit/?id=fc9181ff3d3ebbe0159871f6a49438e60bb17f58 > http://git.zx2c4.com/cgit/commit/?id=b56be4ba3a942dd1978fe4bfecd9afc35aab0027 > So one set of patches or the other does duplicate some functionality. 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 :). So I would vote for keeping both sets of patches: The one above to have a simple standard -- and the new one to allow more fine-grained cgit control if someone needs it. > - There are certain advantages of keeping with the gitweb.* namespace, > as it promotes compatibility and unifies a web-oriented configuration > namespace. "When things are in the gitweb area, it means they should > work with webpages that use git for data." I'm not sure I like the > idea of a general cgit namespace, and then cherry picking special > gitweb.* items. 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'). It certainly depends on what you see the 'gitweb' category to be -- is it 'all web for git' or 'the single product "gitweb"'? > - git_config_from_file should only be called once. This patch series > duplicates the call. Things should be unified into one callback > function. I'll fix this (hopefully this evening). > - The two patches listed above work with the gitolite default, which is nice. So does the new patch. It does not hinder you to use the gitweb-variables. (Again: I'd recommend to keep both patch sets). > - I don't like having the uber gitolite-specific documentation in > there. It seems like a general solution would be more optimal. 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. - Ren?