Hi!
On Tue, Sep 01, 2009 at 01:39:19PM +0200, Jakub Narebski wrote:
> @@ -4806,6 +4820,10 @@ sub git_tag {
>
> sub git_blame_common {
> my $format = shift || 'porcelain';
> + if ($format eq 'porcelain' && $cgi->param('js')) {
> + $format = 'incremental';
> + $action = 'blame_incremental'; # for page title etc
> + }
>
> # permissions
> gitweb_check_feature('blame')
I'm a bit concerned here. I have somewhat backed out of incremental
blame myself because I have found (in accord with Junio's old findings)
that in most cases, incremental blame can be actually slower than normal
blame because of slow browsers where it takes long to update the page in
each step.
I'm sorry if I missed this in one of your mails, but how fast is
incremental blame in your implementation? If this still might be an
issue, I think it should be configurable whether to use incremental
blame, or perhaps use some quick heuristic wrt. file size (negative
bias) and history length (positive bias) [not sure if that information
is quickly available].
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html