[RFD] gitweb configuration

Petr Baudis <pasky@suse.cz> writes:

The problem is we have different types of configuration in gitweb, and we should take care where to put appropriate configuration options/variables.

- build time options, like $gitexecdir ($gitbin now) or $gitweb_version 
  ($version now) which could be set at build time a la ./configure i.e
  my $gitexecdir = "@GIT_EXEC_DIR@"; or something like that.

- gitweb installation options (gitweb version need not to correspond to 
  git version, and we could theoretically have more than one gitweb
  installation while one git-core installation). It was proposed to put
  such options on gitweb.conf file in the same directory as gitweb.cgi.
  Unfortunately if one would want to use git-repo-config for managing
  gitweb.conf one is out of luck: git-repo-config uses $GIT_DIR/config.

  Among installation options we could put also defaults for repository-wide
  (repository specific) options.

  Global gitweb options include:
  * $projectroot - absolute fs-path which will be prepended to the 
    project path, i.e. where projects to display are located (dir)
  * $projects_list - source of projects list (file)
  * $home_text - html text to include at home page (file)
  * $stylesheet - default gitweb stylesheet (file)
  * $git_temp - where to place temporary files (dir)

- repository specific options, of which gitweb for now uses only 
  $GIT_DIR/description, and which could use repository configuration,
  [gitweb] section.

  Repository specific options [can] include:
  * description - One line description of repository; 
    theoretical problem: HTML escaping.
  * blame - to make 'blame'/'annotate' interface available.
  * blobmimemapfile - for repository specific mime map for blob_plain.
  * favicon - if default favicon is not used.

Dear diary, on Sun, Jun 18, 2006 at 12:48:12AM CEST, I got a letter where Jakub Narebski <jnareb@gmail.com> said that...

(Note that this is what Junio said, not me.)

In the longer term, perhaps this kind of configuration might land in the global git configuration file.

--- [PATCH] Support for extracting configuration from different files

Add $GIT_CONFIG environment variable whose content is used instead of .git/config if set. Also add $GIT_CONFIG_LOCAL as a forward-compatibility cue for whenever we will finally come to support] global configuration files (properly).

Signed-off-by: Petr Baudis <pasky@suse.cz>
---

 Documentation/git-repo-config.txt |   12 ++++++++++++
 config.c                          |   12 +++++++++++-
 2 files changed, 23 insertions(+), 1 deletions(-)

Petr Baudis wrote:

We could use user's "global" configuration file, ~/.gitconfig, in patch from Johannes Schindelin (and now in 'pu').

So GIT_CONFIG would be ~/.gitconfig, and GIT_CONFIG_LOCAL would be $GIT_DIR/config or what?

On 6/18/06, Jakub Narebski <jnareb@gmail.com> wrote:

I don't quite follow why gitweb needs a GIT_CONFIG_LOCAL defined. Given that it works in a CGI environment, it should read $GIT_DIR/config by default, and $GIT_CONFIG if set (from httpd.conf).

cheers,

martin

Martin Langhoff wrote:

When talking about gitweb [installation] configuration, including where to find GIT projects to display, one needs to remember that gitweb might (and probably is) installed from binary package and not git.git, and git/.git/config might not exist.

So we have the following options to separate gitweb-wide options:

- use ~/.gitconfig, /etc/gitconfig or some other global git configuration 
  file, reading values using '$gitexecdir/git-repo-config'.
  Problem: bootstraping, namely value of $gitexecdir ($gitbin now)
  needs to be set in gitweb.cgi, perhaps during the build process.

- use gitweb.conf for configuration, reading values via equivalent of
  'GIT_CONFIG=gitweb.conf $gitexecdir/git-repo-config'. 
  Problem: bootstraping, namely value of $gitexecdir ($gitbin now)
  needs to be set in gitweb.cgi, perhaps during the build process.

- use gitweb.conf for configuration, following the .git/config format,
  writing parsing of ini file (reading only) in Perl from scratch 
  (or use one of many CPAN modules).

- use Perl for configuration file, a la Jon Loeliger <jdl@jdl.com> patch:
   http://marc.theaimsgroup.com/?l=git&m=114308224922372&w=2

Jakub Narebski <jnareb@gmail.com> wrote:

Just use "git command" and you don't have to know $gitexecdir.

Timo Hirvonen wrote:

First, 'git' might be not in PATH for the webserver user which runs gitweb.cgi.

Second, I guess that '$gitexecdir/git-repo-config' is/can be faster than 'git repo-config', but if 'git' is in the PATH we can set $gitexecdir from 'git --exec-path'.

Jakub Narebski <jnareb@gmail.com> writes:

For that we would have a chicken-and-egg problem if we make configuration mechanism based on git-repo-config, so I would say per-site customization is needed somehow.

Hardcoding the path into gitweb.cgi could be one way. Hardcoding the path to gitweb per-site configuration file and implement the logic to parse the configuration file without using git-repo-config would be another. Even if you wanted to use "git --exec-path" to bootstrap, not having "git" in the path would make it, eh, cumbersome.

My gut feeling is that it is sensible to assume git is on everybody's path -- after all the site is running gitweb and majority would be using binary packaged distribution, so git would be installed somewhere sensible and accessible.

So I am with Timo on this one, except that in some cases munging gitweb.cgi script itself might be needed if the installation chose to hide git somewhere inaccessible from ordinary users.

Junio C Hamano wrote:

                                                ^^^^^^^^^^^^^^

The problem is with webserver user (nobody, web, apache, ...), which might have nonstandard PATH and/or be run from jail/chroot.

On 6/18/06, Junio C Hamano <junkio@cox.net> wrote:

+1. In the case of binary packages, the maintainer/packager can drop a config file in /etc/apache/conf.d , so it's unlikely that munging actually needs to happen.

cheers,

martin

"Martin Langhoff" <martin.langhoff@gmail.com> writes:

I am not Pasky, but I think the intent of the patch is to run "git repo-config" with GIT_CONFIG pointing at /etc/gitweb.conf to obtain server-wide configuration (e.g. finding out where repositories are) and then when serving individual repository (i.e. after we set up GIT_DIR to point at it) run "git repo-config" without GIT_CONFIG to read per-repository configuration. That way we can reuse the configuration parser.

Dear diary, on Sun, Jun 18, 2006 at 10:38:02AM CEST, I got a letter where Junio C Hamano <junkio@cox.net> said that...

Yes, if $GIT_CONFIG is set, git should be guaranteed to read _no_ config file except $GIT_CONFIG. The intent of $GIT_LOCAL_CONFIG was to make it possible to just override the per-repo configfile location, but it just felt nice to have - I don't insist on it so if people think it's useless additional complexity I'm happy to say that one goodbye.