[RFD] Gitweb: Source configuration from file separate from the CGI script

I just upgraded my Gitweb package (I'm testing the EPEL RHEL5 latest; I'm not too happy with them tweaking the paths) and as I should have expected all of my Gitweb configuration is now gone. Not that it's a big deal to put it back, but we should probably give the option of keeping that configuration information separate from the executable in my opinion. Anybody else want to speak up with respect to this? I have some idea what a prospective patch would look like, but I'd like to hear from people before putting it together (and to let it solidify in my head for a while first as well).

Hi,

Drew Northup wrote:

In gitweb/README, I see:

| You can adjust gitweb behaviour using the file specified in `GITWEB_CONFIG`
| (defaults to 'gitweb_config.perl' in the same directory as the CGI), and
| as a fallback `GITWEB_CONFIG_SYSTEM` (defaults to /etc/gitweb.conf).

Hope that helps, Jonathan

On Wed, 2011-03-16 at 09:34 -0500, Jonathan Nieder wrote:

I apparently missed that. Alas, I didn't see it in the code when I was setting my values so I assumed that it wasn't available. Perhaps we can make this a little more obvious? I'll go try that out and see if I can make it break--putting it in the same directory definitely wouldn't have helped this time.

Drew Northup <drew.northup@maine.edu> writes:

We discourage configuring gitweb by editing generated gitweb.cgi file for a long, long time, at least since v1.4.2-rc2-102-gc8d138a (gitweb: optionally read config from GITWEB_CONFIG, 2006-08-02). It is described in gitweb/README since v1.4.3-rc1-7-g45a3b12 (gitweb: Document features better, 2006-10-07).

Not only gitweb/README; in gitweb.cgi that you are, I suppose, editing, you have $GITWEB_CONFIG mentioned 25 times as a place to override default configuration.

$GITWEB_CONFIG is mentioned 25 times in gitweb source; is it not enough?

How can we make it more obvious? gitweb/INSTALL has "Build time configuration" just below instruction on how to build it, and it mentions "How to configure gitweb for your local system" section in gitweb/README in very first line of this section.

First, as Jonathan cited, you can by default beside 'gitweb_config.perl' in the same directory as the CGI use ' /etc/gitweb.conf' file.

Second, you can configure where GITWEB_CONFIG and GITWEB_CONFIG_SYSTEM are to be found dusing build time, e.g.

  $ make GITWEB_CONFIG_SYSTEM=/etc/gitweb/gitweb_config.perl \
         install-gitweb

Third, you can override where gitweb searches for its config files using GITWEB_CONFIG and/or GITWEB_CONFIG_SYSTEM configuration variables; quite useful for debugging gitweb, and for gitweb tests in git.git repository.

Hey, I don't mean to contribute to the confusion. But, after adding a gitweb_config.perl in the same directory as the cgi I haven't seen all the changes take place. I tried something simple to start like so:

$feature{'blame'}{'override'} = [1]; $feature{'forks'}{'default'} = [1]; $feature{'avatar'}{'default'} = ['gravatar'];

Gravtar is now working, but I haven't seen the blame or forks added. Any help would be appreciated, thanks!

Matt Ryan <matt@devaldez.com> writes:

This doesn't turn on 'blame' feature, but only allows override with per-repository gitweb.blame repository configuration variable.

You probably wanted to use 'default', not 'override' here.

As you can read in comments, this is about very specific layout of repositories, namely that forks of 'path/to/repo.git' are all somewhere below 'path/to/repo' directory.

If you don't have forks organized in such way, you wouldn't see changes from this feature.

This requires that email addresses of authors, committers and taggers have gravatar entry. This means that you have to create "account" on http://www.gravatar.com).

Hope that helps.

Drew Northup wrote:

I came to strong; I am very, very sorry about that. We are really interested how we can make existence and use of gitweb config file more obvious.

The "Build time configuration" section in gitweb/INSTALL is unfortunately after the one-page fold, so that's probably why you didn't notice that. It was probably pushed out by changes in previous section.

What were your changes to gitweb.cgi script, i.e. where in gitweb sources we should add notification about build time and runtime gitweb configuration?

On Thu, 2011-03-17 at 16:41 +0100, Jakub Narebski wrote:

Jakub, I'll have another look soon, perhaps this weekend depending on when I'm done my other obligations. At the very least I'm considering making a man page for the configuration file. I don't know off-hand how much that will be seemingly repetitive of the README, but I suspect I'm not the only one who often finds monolithic files tucked away in /usr/share/doc (/usr/doc for some systems) a daunting reading prospect when I really don't care about the project history since 1937 (which, all too often, was the apparent perspective taken when writing the README). I don't think the gitweb README rises quite to that level, but I do think that benefit may be drawn from doing to it what has been proposed for the rest of gitweb--making it into smaller digestible chunks. I don't plan on bothering anybody here about that until I've had a chance to make a mess in my own repo hacking it to pieces for a while.

Hi Drew,

Drew Northup wrote:

[...]

FWIW, with git-1.7.4.1 in EPEL we now include a commented /etc/gitweb.conf in the package. This wasn't present in the very old 1.5.5.6 we had in EPEL until recently. This config file doesn't list all the available options, but it does point to the README and INSTALL files for further help.

(Also worth noting is that the package was in the epel-testing repository for 3 weeks and was announced on both epel-devel and epel-announce to try and get testing from folks before pushing it stable. Sadly, very few folks do so, and issues are sometimes not caught.)

Sorry if the update caused you trouble.

On Fri, 2011-03-18 at 10:51 -0400, Todd Zullinger wrote:

I did find that following Jonathan's prompting. I hadn't been using the EPEL git packages but had been building my own. Alas I also haven't figured out yet how to auto-exclude individual package sets from upgrade via channel (something for a discussion somewhere else--when I have time to mess with it) and I missed the new EPEL ones in the list. (It's my test/dev box so I let it run packages there for a while first before rolling them out elsewhere.)

The main thing that annoyed me was that EPEL and git's "make rpm" seem to still have very different ideas about where stuff belongs on a machine. I wish I had more time to read the "epel-testing" release notes, but that wouldn't have actually helped me in this case.

Drew Northup wrote:

Yeah, for the EPEL-5 packages, we chose to keep gitexecdir = /usr/bin, so that people updating wouldn't find any scripts broken by the change to /usr/libexec/git-core. This should be good for folks updating from older EPEL packages but not as hot for anyone that had rolled their own from git.git, unfortunately. On the upside, I think that should affect relatively few commands. If you have particular examples, perhaps they are things we can provide better work-arounds for in the EPEL packages?

Drew Northup wrote:

Yes, please! I'd say, beyond that: please feel free to replace large chunks of the README with "See the manpage (or <source file for the manpage>) for further information.".

Happily, Jonathan