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

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: 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

gitweb: accept trailing "/" in $project_list

2012-01-04T17:54:06Z

The current code is removing the trailing "/", but computing the string length on the previous value, i.e. with the trailing "/". Later in the code, we do my $path = substr($File::Find::name, $pfxlen + 1); And the "$pfxlen + 1" is supposed to mean "the length of the prefix, plus 1 for the / separating the prefix and the path", but with an incorrect $pfxlen, this basically eats the first character of the path, and yields "404 - No projects found". While we're there, also fix $pfxdepth to use $dir, although a change of 1 in the depth shouldn't really matter. Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano

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

2011-12-22T23:30:12Z

* jn/maint-gitweb-utf8-fix: gitweb: Fix fallback mode of to_utf8 subroutine gitweb: Output valid utf8 in git_blame_common('data') gitweb: esc_html() site name for title in OPML gitweb: Call to_utf8() on input string in chop_and_escape_str()

gitweb: Fix fallback mode of to_utf8 subroutine

2011-12-19T20:25:43Z

e5d3de5 (gitweb: use Perl built-in utf8 function for UTF-8 decoding., 2007-12-04) was meant to make gitweb faster by using Perl's internals (see subsection "Messing with Perl's Internals" in Encode(3pm) manpage) Simple benchmark confirms that (old = 00f429a, new = this version): old new old -- -65% new 189% -- Unfortunately it made fallback mode of to_utf8 do not work... except for default value 'latin1' of $fallback_encoding ('latin1' is Perl native encoding), which is why it was not noticed for such long time. utf8::valid(STRING) is an internal function that tests whether STRING is in a _consistent state_ regarding UTF-8. It returns true is well-formed UTF-8 and has the UTF-8 flag on _*or*_ if string is held as bytes (both these states are 'consistent'). For gitweb the second option was true, as output from git commands is opened without ':utf8' layer. What made it work at all for STRING in 'latin1' encoding is the fact that utf8:decode(STRING) turns on UTF-8 flag only if source string is valid UTF-8 and contains multi-byte UTF-8 characters... and that if string doesn't have UTF-8 flag set it is treated as in native Perl encoding, i.e. 'latin1' / 'iso-8859-1' (unless native encoding it is EBCDIC ;-)). It was ':utf8' layer that actually converted 'latin1' (no UTF-8 flag == native == 'latin1) to 'utf8'. Let's make use of the fact that utf8:decode(STRING) returns false if STRING is invalid as UTF-8 to check whether to enable fallback mode. Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb: Output valid utf8 in git_blame_common('data')

2011-12-19T03:44:52Z

Otherwise when javascript-actions are enabled gitweb shown broken author names in the tooltips on blame pages ('blame_incremental' view). Signed-off-by: Jürgen Kreileder Acked-by: Jakub Narębski Signed-off-by: Junio C Hamano