"John 'Warthog9' Hawley" <warthog9@xxxxxxxxxxxxxx> writes: > is_cacheable() was set to return false for blame or blame_incremental > which both use unique urls so there's no reason this shouldn't pass > through the caching engine. I have disabled caching 'blame_incremental' (and its workhorse 'blame_data'), in slightly different way (by disabling these views rather than making them un-cacheable), because last time when I was chaing this it simply didn't work with caching. Did you check that it works? Besides with caching (without "tee"-ing captre) 'blame_incremental' view doesn't offer any advantage over 'blame' view, so it should be IMHO disabled. > Leaving the function in place for now should something actually arrise > that we can't use caching for (think ajaxy kinda things likely). Sidenote: I use it for 'cache' and for 'cache_clear' action in "[RFC PATCHv6 24/24] gitweb: Add beginnings of cache administration page (proof of concept)" http://thread.gmane.org/gmane.comp.version-control.git/163052/focus=163051 http://repo.or.cz/w/git/jnareb-git.git/commitdiff/aa9fd77ff206eae8838fdde626d2afea563f9f75 > > Signed-off-by: John 'Warthog9' Hawley <warthog9@xxxxxxxxxxxxxx> > --- > gitweb/gitweb.perl | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl > index 5eb0309..1d8bc74 100755 > --- a/gitweb/gitweb.perl > +++ b/gitweb/gitweb.perl > @@ -798,7 +798,8 @@ our %actions = ( > ); > sub is_cacheable { > my $action = shift; > - return !($action eq 'blame_data' || $action eq 'blame_incremental'); > + # There are no known actions that do no involve a unique URL that shouldn't be cached. > + return 1; > } > > # finally, we have the hash of allowed extra_options for the commands that > -- > 1.7.2.3 > -- Jakub Narebski Poland ShadeHawk on #git -- 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