user/sven/git.git/gitweb, branch v1.7.9.3

Merge branch 'jn/maint-gitweb-invalid-regexp' into maint

2012-03-05T06:17:47Z

* jn/maint-gitweb-invalid-regexp: gitweb: Handle invalid regexp in regexp search

gitweb: Handle invalid regexp in regexp search

2012-02-28T19:45:31Z

When using regexp search ('sr' parameter / $search_use_regexp variable is true), check first that regexp is valid. Without this patch we would get an error from Perl during search (if searching is performed by gitweb), or highlighting matches substring (if applicable), if user provided invalid regexp... which means broken HTML, with error page (including HTTP headers) generated after gitweb already produced some output. Add test that illustrates such error: for example for regexp "*\.git" we would get the following error: Quantifier follows nothing in regex; marked by <-- HERE in m/* <-- HERE \.git/ at /var/www/cgi-bin/gitweb.cgi line 3084. Reported-by: Ramsay Jones Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano

Merge branch 'jn/gitweb-unborn-head' into maint

2012-02-27T23:33:26Z

* jn/gitweb-unborn-head: gitweb: Fix "heads" view when there is no current branch

gitweb: Fix 'grep' search for multiple matches in file

2012-02-20T06:21:35Z

Commit ff7f218 (gitweb: Fix file links in "grep" search, 2012-01-05), added $file_href variable, to reduce duplication and have the fix applied in single place. Unfortunately it made variable defined inside the loop, not taking into account the fact that $file_href was set only if file changed. Therefore for files with multiple matches $file_href was undefined for second and subsequent matches. Fix this bug by moving $file_href declaration outside loop. Adds tests for almost all forms of sarch in gitweb, which were missing from testuite. Note that it only tests if there are no warnings, and it doesn't check that gitweb finds what it should find. Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb: Fix "heads" view when there is no current branch

2012-02-17T16:25:30Z

In a repository whose HEAD points to an unborn branch with no commits, "heads" view and "summary" view (which shows what is shown in "heads" view) compared the object names of commits at the tip of branches with the output from "git rev-parse HEAD", which caused comparison of a string with undef and resulted in a warning in the server log. This can happen if non-bare repository (with default 'master' branch) is updated not via committing but by other means like push to it, or Gerrit. It can happen also just after running "git checkout --orphan " but before creating any new commit on this branch. Rewrite the comparison so that it also works when $head points at nothing; in such a case, no branch can be "the current branch", add a test for it. While at it, rename local variable $head to $head_at, as it points to current commit rather than current branch name (HEAD contents). The code still incorrectly shows all branches that point at the same commit as what HEAD points as "the current branch", even when HEAD is detached. Fixing this bug is outside the scope of this patch. Reported-by: Rajesh Boyapati Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb: Allow UTF-8 encoded CGI query parameters and path_info

2012-02-03T21:03:08Z

Gitweb forgot to turn query parameters into UTF-8. This results in a bug that one cannot search for a string with characters outside US-ASCII. For example searching for "Michał Kiedrowicz" (containing letter 'ł' - LATIN SMALL LETTER L WITH STROKE, with Unicode codepoint U+0142, represented with 0xc5 0x82 bytes in UTF-8 and percent-encoded as %C5%82) result in the following incorrect data in search field MichaÅ\202 Kiedrowicz This is caused by CGI by default treating '0xc5 0x82' bytes as two characters in Perl legacy encoding latin-1 (iso-8859-1), because 's' query parameter is not processed explicitly as UTF-8 encoded string. The solution used here follows "Using Unicode in a Perl CGI script" article on http://www.lemoda.net/cgi/perl-unicode/index.html: use CGI; use Encode 'decode_utf8; my $value = params('input'); $value = decode_utf8($value); Decoding UTF-8 is done when filling %input_params hash and $path_info variable; the former requires to move from explicit $cgi->param() to $input_params{} in a few places, which is a good idea anyway. Also add -override=>1 parameter to $cgi->textfield() invocation in search form. Otherwise CGI would use values from query string if it is present, filling value from $cgi->param... without decode_utf8(). As we are using value of appropriate parameter anyway, -override=>1 doesn't change the situation but makes gitweb fill search field correctly. We could simply use the '-utf8' pragma (via "use CGI '-utf8';") to solve this, but according to CGI.pm documentation, it may cause problems with POST requests containing binary files, and it requires CGI 3.31 (I think), released with perl v5.8.9. Reported-by: Michał Kiedrowicz Signed-off-by: Jakub Narębski Tested-by: Michał Kiedrowicz Signed-off-by: Junio C Hamano

Merge branch 'jn/maint-gitweb-grep-fix'

2012-01-17T00:45:56Z

* jn/maint-gitweb-grep-fix: gitweb: Harden "grep" search against filenames with ':' gitweb: Fix file links in "grep" search

Merge branch 'mm/maint-gitweb-project-maxdepth'

2012-01-09T23:58:30Z

* mm/maint-gitweb-project-maxdepth: gitweb: accept trailing "/" in $project_list

gitweb: Harden "grep" search against filenames with ':'

2012-01-05T21:29:51Z

Run "git grep" in "grep" search with '-z' option, to be able to parse response also for files with filename containing ':' character. The ':' character is otherwise (without '-z') used to separate filename from line number and from matched line. Note that this does not protect files with filename containing embedded newline. This would be hard but doable for text files, and harder or even currently impossible with binary files: git does not quote filename in "Binary file matches" message, but new `--break` and/or `--header` options to git-grep could help here. Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb: Fix file links in "grep" search

2012-01-05T21:29:50Z

There were two bugs in generating file links (links to "blob" view), one hidden by the other. The correct way of generating file link is href(action=>"blob", hash_base=>$co{'id'}, file_name=>$file); It was $co{'hash'} (this key does not exist, and therefore this is undef), and 'hash' instead of 'hash_base'. To have this fix applied in single place, this commit also reduces code duplication by saving file link (which is used for line links) in $file_href. Reported-by: Thomas Perl Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano