Jakub Narebski <jnareb@xxxxxxxxx> writes: > Eli Barzilay <eli@xxxxxxxxxxxx> 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! -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html