threads / patch / 5073

patchgitweb.cgi: Customization

Subject: [PATCH] gitweb.cgi: Customization

## tl;dr

22 messages between Aug 1, 2006 and Aug 3, 2006. Diffs are folded; open one to read it.

replies: 21people: 8as markdown or json

Luben Tuikov· Aug 1, 2006, 21:19 UTC · lore

The file "Gitweb_customization.pm" now holds customizable variables used by "gitweb.cgi". It is read by "gitweb.cgi" from @INC, which includes ".", at compile time.

Copy "Gitweb_customization.pm" to where your "gitweb.cgi" or its link lives. The values therein are default values, please change them as per your setup. From then on, you only need to update (copy) "gitweb.cgi" in order to upgrade it, without editing or patching "gitweb.cgi" itself.

Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
 gitweb/Gitweb_customization.pm |   43 ++++++++++++++++++++++++++++++++++++++++
 gitweb/gitweb.cgi              |   31 +----------------------------
 2 files changed, 44 insertions(+), 30 deletions(-)
Show changes to 2 files +44 −30

gitweb/Gitweb_customization.pm, gitweb/gitweb.cgi

diff --git a/gitweb/Gitweb_customization.pm b/gitweb/Gitweb_customization.pm
new file mode 100644
index 0000000..8bfa19a
--- /dev/null
+++ b/gitweb/Gitweb_customization.pm
@@ -0,0 +1,43 @@
+package    Gitweb_customization;
+require    Exporter;
+
+our @ISA = qw(Exporter);
+our @EXPORT = qw($GIT $projectroot $projects_list $home_text $site_name
+		 $stylesheet $default_blob_plain_mimetype
+		 $default_text_plain_charset $mimetypes_file);
+
+# core git executable to use
+# this can just be "git" if your webserver has a sensible PATH
+our $GIT = "/usr/bin/git";
+
+# absolute fs-path which will be prepended to the project path
+our $projectroot = "/pub/git";
+
+# source of projects list
+# Directory format:
+#our $projects_list = $projectroot;
+# File (shown below) each line in the file is:
+#        [directory.git]<space>[owner.name]
+# (ignore leading whitespace and perl comment char),
+#   where [owner.name] is a sequence of chars with '+' for a space.
+our $projects_list = "index/index.aux";
+
+# html text to include at home page
+our $home_text = "indextext.html";
+
+# name of your site or organization to appear in page titles
+# replace this with something more descriptive for clearer bookmarks
+our $site_name = $ENV{'SERVER_NAME'} || "Untitled";
+
+# URI of default stylesheet
+our $stylesheet = "gitweb.css";
+
+# default blob_plain mimetype and default charset for text/plain blob
+our $default_blob_plain_mimetype = 'text/plain';
+our $default_text_plain_charset  = undef;
+
+# file to use for guessing MIME types before trying /etc/mime.types
+# (relative to the current git repository)
+our $mimetypes_file = undef;
+
+1;
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 9448b72..5251fac 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -15,6 +15,7 @@ use CGI::Carp qw(fatalsToBrowser);
 use Encode;
 use Fcntl ':mode';
 use File::Find qw();
+use Gitweb_customization;
 binmode STDOUT, ':utf8';
 
 our $cgi = new CGI;
@@ -23,14 +24,6 @@ our $my_url = $cgi->url();
 our $my_uri = $cgi->url(-absolute => 1);
 our $rss_link = "";
 
-# core git executable to use
-# this can just be "git" if your webserver has a sensible PATH
-our $GIT = "/usr/bin/git";
-
-# absolute fs-path which will be prepended to the project path
-#our $projectroot = "/pub/scm";
-our $projectroot = "/home/kay/public_html/pub/scm";
-
 # version of the core git binary
 our $git_version = qx($GIT --version) =~ m/git version (.*)$/ ? $1 : "unknown";
 
@@ -43,28 +36,6 @@ if (! -d $git_temp) {
 # target of the home link on top of all pages
 our $home_link = $my_uri;
 
-# name of your site or organization to appear in page titles
-# replace this with something more descriptive for clearer bookmarks
-our $site_name = $ENV{'SERVER_NAME'} || "Untitled";
-
-# html text to include at home page
-our $home_text = "indextext.html";
-
-# URI of default stylesheet
-our $stylesheet = "gitweb.css";
-
-# source of projects list
-#our $projects_list = $projectroot;
-our $projects_list = "index/index.aux";
-
-# default blob_plain mimetype and default charset for text/plain blob
-our $default_blob_plain_mimetype = 'text/plain';
-our $default_text_plain_charset  = undef;
-
-# file to use for guessing MIME types before trying /etc/mime.types
-# (relative to the current git repository)
-our $mimetypes_file = undef;
-
 # input validation and dispatch
 our $action = $cgi->param('a');
 if (defined $action) {
-- 
1.4.2.rc2.gd2da4
Junio C Hamano· Aug 1, 2006, 22:15 UTC · re: Luben Tuikov · lore

Re: [PATCH] gitweb.cgi: Customization

Luben Tuikov <ltuikov@yahoo.com> writes:
> Copy "Gitweb_customization.pm" to where your "gitweb.cgi" or
> its link lives.

I do not think this is a good idea -- there may not be any harm done when http://site/cgi-bin/Gitweb_customization.pm is accessed, but this _does_ pollute the cgi-bin/ namespace.

Luben Tuikov· Aug 1, 2006, 22:53 UTC · re: Junio C Hamano · lore

Re: [PATCH] gitweb.cgi: Customization

--- Junio C Hamano <junkio@cox.net> wrote:
Show 8 quoted lines
> Luben Tuikov <ltuikov@yahoo.com> writes:
> 
> > Copy "Gitweb_customization.pm" to where your "gitweb.cgi" or
> > its link lives.
> 
> I do not think this is a good idea -- there may not be any harm
> done when http://site/cgi-bin/Gitweb_customization.pm is
> accessed, but this _does_ pollute the cgi-bin/ namespace.

As does "gitweb.css". Similarly, "gitweb.css"'s contents used to live in "gitweb.cgi" itself.

"Gitweb_customization.pm" doesn't necessarily need to live in "http://site/cgi-bin/", but anywhere in any path in @INC, i.e. such that it wouldn't be accessible from the outside world.

This method of customization seemed the least intrusive and easiest from re-deployment point of view.

    Luben
Junio C Hamano· Aug 1, 2006, 23:54 UTC · re: Luben Tuikov · lore

Re: [PATCH] gitweb.cgi: Customization

Luben Tuikov <ltuikov@yahoo.com> writes:
> As does "gitweb.css".  Similarly, "gitweb.css"'s contents
> used to live in "gitweb.cgi" itself.

Not convincing argument. gitweb.css, and git-logo.png patch I think I will take, are meant to be fed to the http clients. They do not compare with the customization.pm which is not.

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 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.

Luben Tuikov· Aug 2, 2006, 02:01 UTC · re: Junio C Hamano · lore

Re: [PATCH] gitweb.cgi: Customization

--- Junio C Hamano <junkio@cox.net> wrote:
Show 6 quoted lines
> 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.
Ok, sounds good.
    Luben
Martin Langhoff· Aug 2, 2006, 02:13 UTC · re: Junio C Hamano · lore

Re: [PATCH] gitweb.cgi: Customization

On 8/2/06, Junio C Hamano <junkio@cox.net> wrote:
Show 6 quoted lines
> 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

I'm a bit lost as to gitweb config. Are we not relying on %ENV for this stuff? Apache's facilities to configure CGIs via ENV are really powerful. You can do conditionals in apache config files, lock stuff down in httpd.conf, override it with files in conf.d, and allow/disallow overrides in .htaccess ...

cheers,
martin
Junio C Hamano· Aug 2, 2006, 07:45 UTC · re: Martin Langhoff · lore

Re: [PATCH] gitweb.cgi: Customization

"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> I'm a bit lost as to gitweb config. Are we not relying on %ENV for
> this stuff?

It is Ok to use %ENV as an alternative way, but I'd rather not make it the _only_ way for basic configuration. Not everybody runs Apache.

Martin Langhoff· Aug 2, 2006, 07:59 UTC · re: Junio C Hamano · lore

Re: [PATCH] gitweb.cgi: Customization

On 8/2/06, Junio C Hamano <junkio@cox.net> wrote:
Show 8 quoted lines
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
>
> > I'm a bit lost as to gitweb config. Are we not relying on %ENV for
> > this stuff?
>
> It is Ok to use %ENV as an alternative way, but I'd rather not
> make it the _only_ way for basic configuration.  Not everybody
> runs Apache.
Ho-hum. And are those other webservers limited in their ENV-setting-fu? ;-)

I always thought that any webserver implementing CGI had reasonable means of ENV manipulation, as that's the main mechanism for the webserver to "configure" the CGI program.

But I'm definitely old-style and out-of-fashion in this.
martin
Matthias Lederhofer· Aug 2, 2006, 15:53 UTC · re: Martin Langhoff · lore

Re: [PATCH] gitweb.cgi: Customization

Martin Langhoff <martin.langhoff@gmail.com> wrote:
Show 17 quoted lines
> On 8/2/06, Junio C Hamano <junkio@cox.net> wrote:
> >"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> >
> >> I'm a bit lost as to gitweb config. Are we not relying on %ENV for
> >> this stuff?
> >
> >It is Ok to use %ENV as an alternative way, but I'd rather not
> >make it the _only_ way for basic configuration.  Not everybody
> >runs Apache.
> 
> Ho-hum. And are those other webservers limited in their ENV-setting-fu? ;-)
> 
> I always thought that any webserver implementing CGI had reasonable
> means of ENV manipulation, as that's the main mechanism for the
> webserver to "configure" the CGI program.
> 
> But I'm definitely old-style and out-of-fashion in this.

At least if you cannot change the webserver configuration it might be more complicated to set environment variables.

Martin Waitz· Aug 3, 2006, 06:58 UTC · re: Martin Langhoff · lore

Re: [PATCH] gitweb.cgi: Customization

hoi :)
On Wed, Aug 02, 2006 at 02:13:51PM +1200, Martin Langhoff wrote:
Show 13 quoted lines
> On 8/2/06, Junio C Hamano <junkio@cox.net> wrote:
> >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
> 
> I'm a bit lost as to gitweb config. Are we not relying on %ENV for
> this stuff? Apache's facilities to configure CGIs via ENV are really
> powerful. You can do conditionals in apache config files, lock stuff
> down in httpd.conf, override it with files in conf.d, and
> allow/disallow overrides in .htaccess ...
we could make the default use %ENV.
Something like (in Makefile):

GITWEB_SITENAME = $$ENV{GITWEB_SITENAME} GITWEB_PROJECTROOT = $$ENV{GITWEB_SITENAME} || "/pub/git" ...

and then change gitweb to not put the expanded config values into quotes. So:

our $projectroot = @@GITWEB_PROJECTROOT@@;

This approach would allow both built-time or run-time configuration of gitweb.

-- 
Martin Waitz
Jeff King· Aug 3, 2006, 16:24 UTC · re: Martin Waitz · lore

Re: [PATCH] gitweb.cgi: Customization

On Thu, Aug 03, 2006 at 08:58:52AM +0200, Martin Waitz wrote:
Show 6 quoted lines
> we could make the default use %ENV.
> 
> Something like (in Makefile):
> 
> GITWEB_SITENAME = $$ENV{GITWEB_SITENAME}
> GITWEB_PROJECTROOT = $$ENV{GITWEB_SITENAME} || "/pub/git"

An interesting idea, but it means that gitweb.perl no longer parses as valid perl, since we have things like:

> our $projectroot = @@GITWEB_PROJECTROOT@@;
Do the environment variable names really need to be configurable, or
would something like this work:
  1. accept from config file if it exists and defines $projectroot
  2. otherwise, accept from environment if GITWEB_PROJECTROOT is defined
  3. otherwise, default to compile-time value

Speaking of which, perhaps we should clean up the names of variables that are used by the config file now, before they get into widespread use. The names are very inconsistent (e.g., projectroot, git_temp) and undocumented. We could standardize on something like $GITWEB_PROJECTROOT, matched to GITWEB_PROJECTROOT in the environment and GITWEB_PROJECTROOT in the Makefile.

-Peff
Matthias Lederhofer· Aug 2, 2006, 07:09 UTC · re: Junio C Hamano · lore

Re: [PATCH] gitweb.cgi: Customization

Junio C Hamano <junkio@cox.net> 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.
Ack.
Show 6 quoted lines
> 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.

Functionality is a bit different. If you have a configuration where perl is used this cannot be done using the make variables. I would like to have the option to include a perl file (this does not conflict with using the Makefile to fill in some values), I've explained this in my other patch. The ways I see to specify the file to include are an environment variable (I don't know if all webservers make it easy to set one), files after __DATA__ or just $include_file = @@GITWEB_INCLUDE_FILE@@ which is replaced by the filename or undef if the user did not set this variable. For the .pm thing I don't know if it is not too complicated to change the path I can put the file and just allowing the user to specify the full path is probably the best. (I think the $include_file way is probably the one to use, using __DATA__ is a bit obscur, and not everyone can set environment variables for the webserver.)

Matthias Lederhofer· Aug 2, 2006, 08:54 UTC · re: Matthias Lederhofer · lore

Re: [PATCH] gitweb.cgi: Customization

Just another idea: add something like @@FOO@@ on a line of its own and this is replaced by the content of a file if the user specifies one, nothing if he does not. This way one could include the config directly into gitweb.cgi or include a file that includes the configuration file from another place.

Martin Langhoff· Aug 2, 2006, 09:31 UTC · re: Matthias Lederhofer · lore

Re: [PATCH] gitweb.cgi: Customization

On 8/2/06, Matthias Lederhofer <matled@gmx.net> wrote:
> Just another idea: add something like @@FOO@@ on a line of its own and

We kind-of had that in a few Perl scripts before, and it's a mighty pain to develop and debug from your git repo because it makes your checked-in code invalid.

You might want to see this patch: http://kernel.org/git/?p=git/git.git;a=commitdiff;h=e923effb43fa952f9cb72ffe4c3625fce7655bff;hp=ced9456a27197fc038fbc5b5ebad87e55f1920d2

cheers,
m
Matthias Lederhofer· Aug 2, 2006, 12:55 UTC · re: Martin Langhoff · lore

Re: [PATCH] gitweb.cgi: Customization

Martin Langhoff <martin.langhoff@gmail.com> wrote:
Show 9 quoted lines
> On 8/2/06, Matthias Lederhofer <matled@gmx.net> wrote:
> >Just another idea: add something like @@FOO@@ on a line of its own and
> 
> We kind-of had that in a few Perl scripts before, and it's a mighty
> pain to develop and debug from your git repo because it makes your
> checked-in code invalid.
> 
> You might want to see this patch:
> http://kernel.org/git/?p=git/git.git;a=commitdiff;h=e923effb43fa952f9cb72ffe4c3625fce7655bff;hp=ced9456a27197fc038fbc5b5ebad87e55f1920d2
Perhaps # @@INSERT_YOUR_CODE_HERE@@?
Jon Loeliger· Aug 2, 2006, 16:23 UTC · re: Junio C Hamano · lore

Re: [PATCH] gitweb.cgi: Customization

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.

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.

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.

Show 6 quoted lines
> 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 posted a patch to this end back on March 22 or 23 or so as well.

Thanks, jdl

Jeff King· Aug 2, 2006, 16:53 UTC · re: Jon Loeliger · lore

Re: [PATCH] gitweb.cgi: Customization

On Wed, Aug 02, 2006 at 11:23:22AM -0500, Jon Loeliger wrote:
Show 6 quoted lines
> With this "params in config.mk" approach, I have to
> run it multiple times, once for each web server I run.
>
> 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.

Why don't we have sensible compile-time defaults that can be overridden by a run-time config file like every other sane program? For those who are opposed to the run-time config, they can simply not have a config file.

See the (completely untested) patch below. Obviously the config file
name has to be set at build time. However, since it is interpolated by
perl, you can do clever things like:
  /etc/gitweb/$ENV{MY_VIRTUAL_HOST}.pl
-Peff
---
 Makefile           |    2 ++
 gitweb/gitweb.perl |    3 +++
 2 files changed, 5 insertions(+), 0 deletions(-)
Show changes to 2 files +5 −0

Makefile, gitweb/gitweb.perl

diff --git a/Makefile b/Makefile
index 2562a2c..170d082 100644
--- a/Makefile
+++ b/Makefile
@@ -127,6 +127,7 @@ GIT_PYTHON_DIR = $(prefix)/share/git-cor
 # DESTDIR=
 
 # default configuration for gitweb
+GITWEB_CONFIG = gitweb_config.perl
 GITWEB_SITENAME =
 GITWEB_PROJECTROOT = /pub/git
 GITWEB_LIST =
@@ -629,6 +630,7 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
 	sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
 	    -e 's|@@GIT_VERSION@@|$(GIT_VERSION)|g' \
 	    -e 's|@@GIT_BINDIR@@|$(bindir)|g' \
+	    -e 's|@@GITWEB_CONFIG@@|$(GITWEB_CONFIG)|g' \
 	    -e 's|@@GITWEB_SITENAME@@|$(GITWEB_SITENAME)|g' \
 	    -e 's|@@GITWEB_PROJECTROOT@@|$(GITWEB_PROJECTROOT)|g' \
 	    -e 's|@@GITWEB_LIST@@|$(GITWEB_LIST)|g' \
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1db1414..cc33d97 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -66,6 +66,9 @@ # file to use for guessing MIME types be
 # (relative to the current git repository)
 our $mimetypes_file = undef;
 
+our $GITWEB_CONFIG = "@@GITWEB_CONFIG@@";
+require $GITWEB_CONFIG if -e $GITWEB_CONFIG;
+
 # input validation and dispatch
 our $action = $cgi->param('a');
 if (defined $action) {
-- 
1.4.2.rc2.g59706-dirty
Matthias Lederhofer· Aug 2, 2006, 17:13 UTC · re: Jeff King · lore

Re: [PATCH] gitweb.cgi: Customization

Jeff King <peff@peff.net> wrote:
Show 10 quoted lines
> On Wed, Aug 02, 2006 at 11:23:22AM -0500, Jon Loeliger wrote:
> Why don't we have sensible compile-time defaults that can be overridden
> by a run-time config file like every other sane program? For those who
> are opposed to the run-time config, they can simply not have a config
> file.
> 
> See the (completely untested) patch below. Obviously the config file
> name has to be set at build time. However, since it is interpolated by
> perl, you can do clever things like:
>   /etc/gitweb/$ENV{MY_VIRTUAL_HOST}.pl
I like this (it is quite similar to my suggestions :)).
Show 12 quoted lines
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -66,6 +66,9 @@ # file to use for guessing MIME types be
>  # (relative to the current git repository)
>  our $mimetypes_file = undef;
>  
> +our $GITWEB_CONFIG = "@@GITWEB_CONFIG@@";
> +require $GITWEB_CONFIG if -e $GITWEB_CONFIG;
> +
>  # input validation and dispatch
>  our $action = $cgi->param('a');
>  if (defined $action) {

The only other thing to change is to move the mkdir($git_temp) and qx($GIT --version) below this line.

Jakub Narebski· Aug 2, 2006, 17:34 UTC · re: Jeff King · lore

Re: [PATCH] gitweb.cgi: Customization

Jeff King wrote:
Show 18 quoted lines
> On Wed, Aug 02, 2006 at 11:23:22AM -0500, Jon Loeliger wrote:
> 
>> With this "params in config.mk" approach, I have to
>> run it multiple times, once for each web server I run.
>>
>> 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.
> 
> Why don't we have sensible compile-time defaults that can be overridden
> by a run-time config file like every other sane program? For those who
> are opposed to the run-time config, they can simply not have a config
> file.
> 
> See the (completely untested) patch below. Obviously the config file
> name has to be set at build time. However, since it is interpolated by
> perl, you can do clever things like:
>   /etc/gitweb/$ENV{MY_VIRTUAL_HOST}.pl
Besides, we can use _relative_ paths.
I like this proposal the best.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Junio C Hamano· Aug 2, 2006, 17:43 UTC · re: Jeff King · lore

Re: [PATCH] gitweb.cgi: Customization

Jeff King <peff@peff.net> writes:
> Why don't we have sensible compile-time defaults that can be overridden
> by a run-time config file like every other sane program?
I like that approach.
Luben Tuikov· Aug 2, 2006, 20:30 UTC · re: Jon Loeliger · lore

Re: [PATCH] gitweb.cgi: Customization

--- Jon Loeliger <jdl@freescale.com> wrote:
Show 13 quoted lines
> 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.

Show 8 quoted lines
> > 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
Matthias Lederhofer· Aug 2, 2006, 19:40 UTC · re: Junio C Hamano · lore

Re: [PATCH] gitweb.cgi: Customization

Junio C Hamano <junkio@cox.net> wrote:
> 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.

I hope it will be possible (see require suggestion from Jeff King) to specify the file also from the environment because then it is possible to develop on an uncostumized version of gitweb.perl. Now I noticed a problem: do not use the @@FOO@@ in double quotes because perl will spit a lot of warnings like "Possible unintended interpolation of @GIT_VERSION in string" Either we should use another delimiter or use single quotes (this is the way it is done in git-send-email.perl and git-svn.perl). I don't know how likely it is that characters that are interpreted different in double quotes are in filenames but I'd prefer single quotes just to be on the safe site. This disallows using '/etc/foo/$ENV{SITE_NAME}' as config file but one can just use '/etc/foo/bar' which requires '/etc/foo/$ENV{SITE_NAME}'.

← back to recent threads