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

[Jamie Couture]

On Mon, Oct 8, 2012 at 5:27 PM, Jason A. Donenfeld <Jason at zx2c4.com> 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
>