delta/git.git/gitweb, branch zj/diff-stat-dyncol

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

2012-01-17T00:45:56+00:00

* 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:30+00:00

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

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

2012-01-05T21:29:51+00:00

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:50+00:00

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:06+00:00

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:12+00:00

* 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:43+00:00

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:52+00:00

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

gitweb: esc_html() site name for title in OPML

2011-12-19T03:44:51+00:00

This escapes the site name in OPML (XML uses the same escaping rules
as HTML).  Also fixes encoding issues because esc_html() uses
to_utf8().

Signed-off-by: Jürgen Kreileder 
Acked-by: Jakub Narębski 
Signed-off-by: Junio C Hamano

gitweb: Call to_utf8() on input string in chop_and_escape_str()

2011-12-19T03:44:51+00:00

a) To fix the comparison with the chopped string,
   otherwise we compare bytes with characters, as
   chop_str() must run to_utf8() for correct operation
b) To give the title attribute correct encoding;
   we need to mark strings as UTF-8 before outpur

Signed-off-by: Jürgen Kreileder 
Acked-by: Jakub Narębski 
Signed-off-by: Junio C Hamano