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

gitweb: Fix snapshots requested via PATH_INFO

2009-04-20T10:42:23Z

Fix the detection of the requested snapshot format, which failed for PATH_INFO URLs since the references to the hashes which describe the supported snapshot formats weren't dereferenced appropriately. Signed-off-by: Holger Weiß Acked-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb: Hyperlink multiple git hashes on the same commit message line

2009-02-20T06:49:55Z

The current implementation only hyperlinks the first hash on a given line of the commit message. It seems sensible to highlight all of them if there are multiple, and it seems plausible that there would be multiple even with a tidy line length limit, because they can be abbreviated as short as 8 characters. Benchmark: I wanted to make sure that using the 'e' switch to the Perl regex wasn't going to kill performance, since this is called once per commit message line displayed. In all three A/B scenarios I tried, the A and B yielded the same results within 2%, where A is the version of code before this patch and B is the version after. 1: View a commit message containing the last 1000 commit hashes 2: View a commit message containing 1000 lines of 40 dots to avoid hyperlinking at the same message length 3: View a short merge commit message with a few lines of text and no hashes All were run in CGI mode on my sub-production hardware on a recent clone of git.git. Numbers are the average of 10 reqests per second with the first request discarded, since I expect this change to affect primarily CPU usage. Measured with ApacheBench. Note that the web page rendered was the same; while the new code supports multiple hashes per line, there was at most one per line. The primary purpose of scenarios 2 and 3 were to verify that the addition of 1000 commit messages had an impact on how much of the time was spent rendering commit messages. They were all within 2% of 0.80 requests per second (much faster). So I think the patch has no noticeable effect on performance. Signed-off-by: Marcel M. Cary Acked-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb: Fix warnings with override permitted but no repo override

2009-02-18T18:43:21Z

When a feature like "blame" is permitted to be overridden in the repository configuration but it is not actually set in the repository, a warning is emitted due to the undefined value of the repository configuration, even though it's a perfectly normal condition. Emitting warning is grounds for test failure in the gitweb test script. This error was caused by rewrite of git_get_project_config from using "git config [] " for each individual configuration variable checked to parsing "git config --list --null" output in commit b201927 (gitweb: Read repo config using 'git config -z -l'). Earlier version of git_get_project_config was returning empty string if variable do not exist in config; newer version is meant to return undef in this case, therefore change in feature_bool was needed. Additionally config_to_* subroutines were meant to be invoked only if configuration variable exists; therefore we added early return to git_get_project_config: it now returns no value if variable does not exists in config. Otherwise config_to_* subroutines (config_to_bool in paryicular) wouldn't be able to distinguish between the case where variable does not exist and the case where variable doesn't have value (the "[section] noval" case, which evaluates to true for boolean). While at it fix bug in config_to_bool, where checking if $val is defined (if config variable has value) was done _after_ stripping leading and trailing whitespace, which lead to 'Use of uninitialized value' warning. Add test case for features overridable but not overriden in repo config, and case for no value boolean configuration variable. Signed-off-by: Marcel M. Cary Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb: fix wrong base URL when non-root DirectoryIndex

2009-02-17T00:19:07Z

CGI::url() has some issues when rebuilding the script URL if the script is a DirectoryIndex. One of these issue is the inability to strip PATH_INFO, which is why we had to do it ourselves. Another issue is that the resulting URL cannot be used for the tag: it works if we're the DirectoryIndex at the root level, but not otherwise. We fix this by building the proper base URL ourselves, and improve the comment about the need to strip PATH_INFO manually while we're at it. Additionally t/t9500-gitweb-standalone-no-errors.sh had to be modified to set SCRIPT_NAME variable (CGI standard states that it MUST be set, and now gitweb uses it if PATH_INFO is not empty, as is the case for some of tests in t9500). Signed-off-by: Giuseppe Bilotta Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano

Merge branch 'jn/gitweb-committag'

2009-02-15T09:44:11Z

* jn/gitweb-committag: gitweb: Better regexp for SHA-1 committag match

Merge branch 'maint'

2009-02-09T06:07:53Z

* maint: gitweb: add $prevent_xss option to prevent XSS by repository content rev-list: fix showing distance when using --bisect-all

gitweb: add $prevent_xss option to prevent XSS by repository content

2009-02-09T05:51:25Z

Add a gitweb configuration variable $prevent_xss that disables features to prevent content in repositories from launching cross-site scripting (XSS) attacks in the gitweb domain. Currently, this option makes gitweb ignore README.html (a better solution may be worked out in the future) and serve a blob_plain file of an untrusted type with "Content-Disposition: attachment", which tells the browser not to show the file at its original URL. The XSS prevention is currently off by default. Signed-off-by: Matt McCutchen Signed-off-by: Junio C Hamano

gitweb: Better regexp for SHA-1 committag match

2009-02-07T20:50:49Z

Make SHA-1 regexp to be turned into hyperlink (the SHA-1 committag) to match word boundary at the beginning and the end. This way we reduce number of false matches, for example we now don't match 0x74a5cd01 which is hex decimal (for example memory address), but is not SHA-1. Suggested-by: Johannes Schindelin Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb: align comments to code

2009-01-31T05:08:49Z

Signed-off-by: Giuseppe Bilotta Acked-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb: make static files accessible with PATH_INFO

2009-01-31T05:08:24Z

Gitweb links to a number of static files such as CSS stylesheets, favicon or the git logo. When, such as with the default Makefile, the paths to these files are relative (i.e. doesn't start with a "/"), the files become inaccessible in any view other tha project list and summary page if gitweb is invoked with a non-empty PATH_INFO. Fix this by adding a element pointing to the script's own URL, which ensure that all relative paths will be resolved correctly. Signed-off-by: Giuseppe Bilotta Acked-by: Jakub Narebski Signed-off-by: Junio C Hamano