From mboxrd@z Thu Jan 1 00:00:00 1970 From: jamie.couture at gmail.com (Jamie Couture) Date: Tue, 9 Oct 2012 07:02:23 -0400 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: On Mon, Oct 8, 2012 at 5:27 PM, Jason A. Donenfeld wrote: > Hi Ren?, > > I've merged these changes into a branch in the repo: > http://git.zx2c4.com/cgit/log/?h=rn/gitconfig > > I'd like to mull over them for a few days and not to hastily merge > them into master for a couple of reasons. > > - 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. > > - 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. > I'm okay with it being referred to as gitweb.* section that can configure cgit - but maybe that might be confusing, again, due to there being a different product under the same name. I'm also okay with it being a cgit. namespace - as it is aid in configuring cgit. I do think it's necessary since we pick something to be consistent, which is why I initially chose 'repo.' as it was the cgitrc configuration terminology to avoid confusing cgit users. I mostly use this for section / defbranch and about - it's quite helpful. > > - git_config_from_file should only be called once. This patch series > duplicates the call. Things should be unified into one callback > function. > > No problem; this was only done originally since it was a quick patch to help support those who wanted the feature. - The two patches listed above work with the gitolite default, which is > nice. > > - I don't like having the uber gitolite-specific documentation in > there. It seems like a general solution would be more optimal. On the > other hand, since cgit is so commonly used alongside gitolite, we > could creep gradually in this direction, thought I don't think this > was ever Lars' intention. > > What are your thoughts? > > Jason > > _______________________________________________ > cgit mailing list > cgit at hjemli.net > http://hjemli.net/mailman/listinfo/cgit >