git/gitweb/gitweb.perl, branch v1.7.0.5

gitweb: git_get_project_config requires only $git_dir, not also $project

2010-03-31T17:57:04Z

Fix overeager early return in git_get_project_config, introduced in 9be3614 (gitweb: Fix project-specific feature override behavior, 2010-03-01). When git_get_project_config is called from projects list page via git_get_project_owner($path) etc., it is called with $git_dir defined (in git_get_project_owner($path) etc.), but $project variable is not defined. git_get_project_config doesn't use $project variable anyway. Reported-by: Tobias Heinlein Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano

Merge branch 'jn/gitweb-config-error-die' into maint

2010-03-05T06:27:12Z

* jn/gitweb-config-error-die: gitweb: Die if there are parsing errors in config file

gitweb: Fix project-specific feature override behavior

2010-03-02T20:14:44Z

This commit fixes a bug in processing project-specific override in a situation when there is no project, e.g. for the projects list page. When 'snapshot' feature had project specific config override enabled by putting $feature{'snapshot'}{'override'} = 1; (or equivalent) in $GITWEB_CONFIG, and when viewing toplevel gitweb page, which means the projects list page (to be more exact this happens for any project-less action), gitweb would put the following Perl warnings in error log: gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at gitweb.cgi line 2065. fatal: error processing config file(s) gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at gitweb.cgi line 2221. gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at gitweb.cgi line 2218. The problem is in the following fragment of code: # path to the current git repository our $git_dir; $git_dir = "$projectroot/$project" if $project; # list of supported snapshot formats our @snapshot_fmts = gitweb_get_feature('snapshot'); @snapshot_fmts = filter_snapshot_fmts(@snapshot_fmts); For the toplevel gitweb page, which is the list of projects, $project is not defined, therefore neither is $git_dir. gitweb_get_feature() subroutine calls git_get_project_config() if project specific override is turned on... but we don't have project here. Those errors mentioned above occur in the following fragment of code in git_get_project_config(): # get config if (!defined $config_file || $config_file ne "$git_dir/config") { %config = git_parse_project_config('gitweb'); $config_file = "$git_dir/config"; } git_parse_project_config() calls git_cmd() which has '--git-dir='.$git_dir There are (at least) three possible solutions: 1. Harden gitweb_get_feature() so that it doesn't call git_get_project_config() if $project (and therefore $git_dir) is not defined; there is no project for project specific config. 2. Harden git_get_project_config() like you did in your fix, returning early if $git_dir is not defined. 3. Harden git_cmd() so that it doesn't add "--git-dir=$git_dir" if $git_dir is not defined, and change git_get_project_config() so that it doesn't even try to access $git_dir if it is not defined. This commit implements both 1.) and 2.), i.e. gitweb_get_feature() doesn't call project-specific override if $git_dir is not defined (if there is no project), and git_get_project_config() returns early if $git_dir is not defined. Add a test for this bug to t/t9500-gitweb-standalone-no-errors.sh test. Reported-by: Eli Barzilay Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb: Die if there are parsing errors in config file

2010-02-15T02:50:22Z

Otherwise the errors can propagate, and show in damnest places, and you would spend your time chasing ghosts instead of debugging real problem (yes, it is from personal experience). This follows (parts of) advice in `perldoc -f do` documentation. This required restructoring code a bit, so we die only if we are reading (executing) config file. As a side effect $GITWEB_CONFIG_SYSTEM is always available, even when we use $GITWEB_CONFIG. Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb: Simplify (and fix) chop_str

2010-02-04T01:14:00Z

The chop_str subroutine is meant to be used on strings (such as commit description / title) *before* HTML escaping, which means before applying esc_html or equivalent. Therefore get rid of the failed attempt to always remove full HTML entities (like e.g. & or ). It is not necessary (HTML entities gets added later), and it can cause chop_str to chop a string incorrectly. Specifically: API & protocol: support option to force written data immediately to disk from http://git.kernel.org/?p=daemon/distsrv/chunkd.git;a=commit;h=3b02f749df2cb1288f345a689d85e7061f507e54 The short version of the title gets chopped to API ... where it should be API & protocol: support option to force written data... Noticed-by: John 'Warthog9' Hawley Signed-off-by: John 'Warthog9' Hawley Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb: Add optional extra parameter to die_error, for extended explanation

2010-01-30T23:53:55Z

Add a 3rd, optional, parameter to die_error to allow for extended error information to be output along with what the error was. Signed-off-by: John 'Warthog9' Hawley Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb: add a "string" variant of print_sort_th

2010-01-30T23:53:54Z

Add a function (named format_sort_th) that returns the string that print_sort_th would print. Signed-off-by: John 'Warthog9' Hawley Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb: add a "string" variant of print_local_time

2010-01-30T23:53:54Z

Add a function (named format_local_time) that returns the string that print_local_time would print. Signed-off-by: John 'Warthog9' Hawley Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb: Check that $site_header etc. are defined before using them

2010-01-30T23:53:53Z

If one of $site_header, $site_footer or $home_text is not defined, you get extraneous errors in the web logs, for example (line wrapped for better readibility): [Wed Jan 13 16:55:42 2010] [error] [client ::1] [Wed Jan 13 16:55:42 2010] gitweb.cgi: Use of uninitialized value $site_header in -f at /var/www/gitweb/gitweb.cgi line 3287., referer: http://git/gitweb.cgi This ensures that those variables are defined before trying to use it. Note that such error can happen only because of an error in gitweb config file; building gitweb.cgi can make mentioned variables holding empty string (it is even the default), but they are still defined. Signed-off-by: John 'Warthog9' Hawley Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb: Load checking

2010-01-30T23:53:50Z

This changes slightly the behavior of gitweb, so that it verifies that the box isn't inundated with before attempting to serve gitweb. If the box is overloaded, it basically returns a 503 Server Unavailable until the load falls below the defined threshold. This helps dramatically if you have a box that's I/O bound, reaches a certain load and you don't want gitweb, the I/O hog that it is, increasing the pain the server is already undergoing. This behavior is controlled by $maxload configuration variable. Default is a load of 300, which for most cases should never be hit. Unset it (set it to undefined value, i.e. undef) to turn off checking. Currently it requires that '/proc/loadavg' file exists, otherwise the load check is bypassed (load is taken to be 0). So platforms that do not implement '/proc/loadavg' currently cannot use this feature (provisions are included for additional checks to be added by others). There is simple test in t/t9501-gitweb-standalone-http-status.sh to check that it correctly returns "503 Service Unavailable" if load is too high, and also if there are any Perl warnings or errors. Signed-off-by: John 'Warthog9' Hawley Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano