Re: [PATCH 0/2] gitweb: Improve handling of configuration files

["J.H." <warthog9@kernel.org>]

On 05/25/2011 09:35 AM, Jakub Narebski wrote:
> This two-in-one series is response to Junio's concerns about being
> backwards-incompatibile and different ways of solving "system-wide
> policy" problem.

I realize I'm jumping on this mid way through, but I did read back
through the history.

Start with Patch 1, it looks fine and I support the change.  Makes it a
lot easier to include config files.

> Patches 2/2 version A and 2/2 version B are mutually exclusive.
> Junio, you would have to choose which one to include.

To speak to Junio's concerns seem to boil down to a general concern that
something in /etc/gitweb.conf may interfere with unintended interaction
in the local repository, and has suggested that we do an explicit
include to solve the problem.

I would argue against this, for a couple of reasons:

1) Git itself treats /etc/git.conf in this exact manor, it reads in
stuff from /etc/git.conf and then local repos can change or override
things as needed.  In fact this is quite beneficial, because it gives
site admins a simple and easy way to give an automatic hint to a repo
about things the admin would like.

Case in point turning on things like updateserverinfo, or automatic packing.

The fact that an admin doesn't need to do anything for this change to be
effective in most places is actually the expected result of the
sysadmin.  The systems administrator is saying "hey we need to have this
on everywhere and instead of getting 100 people to all change their
configs, we make one change and the hint is automatically everywhere".

>From a kernel.org perspective, that's what I'd expect.  I'm not keen on
having to go and either add some include line to each config file for
gitweb config (which feels like a kludge) just to centralize config
elements.

2) Trying to get people to do includes in their config files, or to
completely ignore the system wide config isn't a sustainable practice.
It would be akin to asking that every repository on kernel.org add
something to their config, which each individual person has to go and
add on their own.

That's akin to asking 400 people to make a change to 900+ repositories,
and then to remember to make that change for every new repo that gets
created.

Now I don't have 900 instances of gitweb running, but I am up to at
least 3 independent instances, and I can think of a 4th that is in the
works.  Having a system-wide config that gives the basics is appealing
to me.

Now that I've said all that, here's what I propose.

We go back to the way Jakub proposed this originally, where it reads in
the system wide config, and then overwrites things from the local
config.  This really is more in line with what people, particularly
system wide sysadmins, will expect.

To alleviate the concerns of people who thing the systemwide may cause
problems I propose, instead of an explicit include, we do an explicit
exclude for the system wide config.  We have a new config directive that
basically says throw out the systemwide config, take me back to defaults
and let me override from there.  This means needing to either store a
copy of the defaults on start-up, or like with gitweb-caching the
defaults are kept in a separate file and can just be re-read, and it
means that the local config would need to be read twice.

This means that if the individual wants to ignore the hints the systems
administrator is giving in system wide config, then they are making an
explicit choice to do so, either because they know better or something
like git-instaweb where it generally doesn't trust it.  Either way, it's
the exceptions who are making the choice, not the general case.

I'll admit this might even convince me that a single configuration
structure for the entire script is better than individual variable names.

- John 'Warthog9' Hawley