Re: gitweb problem?

[Eli Barzilay <eli@barzilay.org>]

Jakub Narebski <jnareb@gmail.com> writes:

> Eli Barzilay <eli@barzilay.org> writes:
>
>> Whenever I view the toplevel gitweb page (running as a cgi script
>> under apache), but not when in a specific repo, I get this in my error
>> log:
>> 
>> gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at /home/git/gitweb/gitweb.cgi line 2065.
>> fatal: error processing config file(s)
>> gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at /home/git/gitweb/gitweb.cgi line 2221.
>> gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at /home/git/gitweb/gitweb.cgi line 2218.
>> 
>> (taken verbatim from the apache error log, removed uninteresting line
>> prefixes.)
>
> In the future (or if my diagnosis would turn out to be incorrect)
> could you please show which lines are those (in *your* gitweb.cgi),
> or at least provide gitweb version?  Changes to gitweb can render
> such line numbers invalid.

Sorry, I should have mentioned that this is from 1.7.0 -- my file is
not modified, and built with no changes to the defaults except for
prefix=/usr/local.  In any case, the script -- with the test that I
added -- is at http://tmp.barzilay.org/x1 .


>> I'm using the pathinfo option, so perhaps there is a problem with
>> that setup?
>
> In the future (or if my diagnosis would turn out to be incorrect)
> could you please include relevant parts of $GITWEB_CONFIG (by
> default it is gitweb_config.perl), at least which features you have
> enabled, and how they are configured?

http://tmp.barzilay.org/x2 (but see below).


>> Looking at the source, the last two line numbers are in
>> `git_get_project_config' -- so my guess is that the code is trying to
>> get the options from the repository config file even when showing the
>> toplevel page.  Based on this, and also guessing that $git_dir is
>> unset when viewing the toplevel page, I added
>> 
>> 	return unless (defined $git_dir);
>> 
>> to the top (of the `git_get_project_config' function), and I get no
>> warnings and everything works as it should.
>> 
>> (Disclaimer: I can barely read perl, and I'm a git newbie, so all of
>> this can be due to some other stupid mistake.)
>
> That looks like lack of hardening against pilot error.  The
> git_get_project_config should never be run when $git_dir is not set,
> as it is meant to access *project* config.
>
> But at the top of git_project_list_body subroutine, which is
> responsible for generating toplevel page with list of projects, we
> have:
> 	my $check_forks = gitweb_check_feature('forks');
> and a bit later
> 	my $show_ctags = gitweb_check_feature('ctags');
>
> Now both of those features are marked as not supporting project specific
> override.  It might be that you by accident set $feature{XXX}{'override'}
> to true... but I might be mistaken.

No, that's not it.  I've tracked all calls to
`git_get_project_config', and the two offending calls are the ones in
`feature_snapshot' and `feature_avatar'.  I then verified that
commenting out these two lines in my config

  $feature{'snapshot'}{'override'} = 1;
  $feature{'avatar'}{'override'} = 1;

avoids the calls -- and the comments indicate that it should be fine
to do that.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!