Subject: Re: [PATCH] Do not chop HTML tags in commit search result

From: Jakub Narebski <[email-masked]>
Date: Wed, 13 Feb 2008 11:16:15 -0800 (PST)

"Jean-Baptiste Quenot" <[email-masked]> writes:

> Thanks for Git! It's a great program.  I encountered an annoying bug
> with gitweb 1.5.4.1, when searching for commits, if the search string
> is too long, the generated HTML is munged leading to an ill-formed
> XHTML document.
> 
> Here is the patch, hope it helps:

It would be better if the patch wasn't wrapped and whitespace
corrupted.

> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index ae2d057..2c0b990 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -3780,7 +3780,10 @@ sub git_search_grep_body {
>                                 my $trail = esc_html($3) || "";
>                                 $trail = chop_str($trail, 30, 10);
>                                 my $text = "$lead<span class=\"match\">$match</span>$trail";
> -                               print chop_str($text, 80, 5) . "<br/>\n";
> +                               # Do not chop $text as match can be long, and we don't want to
> +                               # munge HTML tags!
> +                               #print chop_str($text, 80, 5) . "<br/>\n";
> +                               print $text . "<br/>\n";
>                         }
>                 }
>                 print "</td>\n" .

While this might be good bigfix, I think it is not a good solution. If
we select to show only neighbourhood of the match, we should probably
chop trailing text, or both leading (cutting at beginning) and
trailing, perhaps even match if it is overly long.

Or we could alternatively show all lines of commit message, and only
mark matching fragment... but that I think would have to wait for
refactoring of generation of log-like views (log, shorlog, history,
rss) in gitweb.

-- 
Jakub Narebski
Poland
ShadeHawk on #git