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

[René Neumann]

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é