Re: [PATCH] gitweb.cgi: Customization

[Luben Tuikov <ltuikov@yahoo.com>]

--- Jon Loeliger <jdl@freescale.com> wrote:
> On Tue, 2006-08-01 at 18:54, Junio C Hamano wrote:
> 
> > In any case, I think tweaking gitweb.cgi from Makefile like
> > Martin Waitz did is as easy and clean for people who want to
> > customize; it should just be the matter of defining the
> > necessary params in config.mak.
> 
> I disagree.  I run multiple virtual web servers on one
> physical machine.  Several of them run different gitweb
> instances, each with different configurations.
> 
> With this "params in config.mk" approach, I have to
> run it multiple times, once for each web server I run.

That's exactly my sentiments.

> I _really_ would prefer an "include from ." feature
> where I can place the specific gitweb_config.pm parts
> in the same directory where gitweb.{pl,cgi} is installed.

Yes, this approach is simple and straightforward enough.
When upgrading, one only needs to do a "cp".

> We really need to separate out these config values
> from the gitweb.{pl,cgi} script itself.  We _need_ to
> be able to update the gitweb script independently,
> and easily.

That's exactly where I was going with this patch.
I don't want to have to:
  - configure httpd, or
  - configure the environment of user "apache", or
  - have a separate forked off branch in order to "configure"
    gitweb at compile time for each gitweb instance I'm running,
  - etc, etc, etc.

Configuration, especially of user space programs should be
completely dynamic.  Compilation for user space programs should
be a separate process from configuration.

> > I do not think there is much difference between any of the
> > customization proposed so far (yours, Martin's and the one from
> > Matthias Lederhofer) from functionality and ease-of-use point of
> > view.  They all try to make customization can be done in one
> > place, and the difference is mostly of taste, so I'd just pick
> > one from Martin.
> 
> Let's just make sure it is a separate config file, please.

I thing your and mine deployment are pretty similar, thus warranting
a more flexible approach, withouth having to recompile or reconfigure
completely unrelated programs and users.

    Luben