{"thread":{"id":"29452","subject":"[PATCH] gitweb: add pf= to limit project list to a subdirectory","startedAt":"2012-01-26T14:45:22Z","lastAt":"2012-01-28T16:03:06Z","messageCount":6,"participants":["Bernhard R. Link","Jakub Narebski"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"183169","messageId":"20120126144517.GA4229@server.brlink.eu","threadId":"29452","inReplyTo":null,"subject":"[PATCH] gitweb: add pf= to limit project list to a subdirectory","fromName":"Bernhard R. Link","fromEmail":"brl+list+git@mail.brlink.eu","sentAt":"2012-01-26T14:45:22Z","receivedAt":"2012-01-26T14:45:22Z","isPatch":true,"sender":{"key":"brl+list+git@mail.brlink.eu","avatar":null},"body":"This commit changes the project listings (project_list, project_index\nand opml) to limit the output to only projects in a subdirectory if the\nnew optional parameter ?pf=directory name is used.\n\nIt uses the infrastructure already there for 'forks' (which also filters\nprojects but needs a project called like the filter directory to work).\n\nThis feature is disabled if strict_export is used and there is no\nprojects_list to avoid showing more than intended.\nWithout strict_export enabled this change should not show any projects\none could not get details from anyway. So if the validate_pathname\nchecks are not sufficient this would at most make it easier to get a\nlist of viewable content.\n\nReusing $project instead of adding a new parameter would have been\nnicer from a UI point-of-view (including PATH_INFO support) but\ncomplicate the $project validating code that is currently being\nused to ensure nothing is exported that should not be viewable.\n\nSigned-off-by: Bernhard R. Link <brlink@debian.org>\n\n---\nAs most parameters are not documented in documentation/gitweb.txt,\nI did not add documentation for this one either.\n\n gitweb/gitweb.perl |   26 ++++++++++++++++++++++----\n 1 files changed, 22 insertions(+), 4 deletions(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex abb5a79..00dd79e 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -760,6 +760,7 @@ our @cgi_param_mapping = (\n \tsearch_use_regexp => \"sr\",\n \tctag => \"by_tag\",\n \tdiff_style => \"ds\",\n+\tproject_filter => \"pf\",\n \t# this must be last entry (for manipulation from JavaScript)\n \tjavascript => \"js\"\n );\n@@ -976,7 +977,7 @@ sub evaluate_path_info {\n \n our ($action, $project, $file_name, $file_parent, $hash, $hash_parent, $hash_base,\n      $hash_parent_base, @extra_options, $page, $searchtype, $search_use_regexp,\n-     $searchtext, $search_regexp);\n+     $searchtext, $search_regexp, $project_filter);\n sub evaluate_and_validate_params {\n \tour $action = $input_params{'action'};\n \tif (defined $action) {\n@@ -994,6 +995,16 @@ sub evaluate_and_validate_params {\n \t\t}\n \t}\n \n+\tour $project_filter = $input_params{'project_filter'};\n+\tif (defined $project_filter) {\n+\t\tif ($strict_export and -d $projects_list) {\n+\t\t\tdie_error(404, \"project_filter disabled\");\n+\t\t}\n+\t\tif (!validate_pathname($project_filter)) {\n+\t\t\tdie_error(404, \"Invalid project_filter parameter\");\n+\t\t}\n+\t}\n+\n \tour $file_name = $input_params{'file_name'};\n \tif (defined $file_name) {\n \t\tif (!validate_pathname($file_name)) {\n@@ -3962,6 +3973,13 @@ sub git_footer_html {\n \t\t\t              -class => $feed_class}, $format).\"\\n\";\n \t\t}\n \n+\t} elsif (defined $project_filter) {\n+\t\tprint $cgi->a({-href => href(project=>undef, action=>\"opml\",\n+\t\t                             project_filter => $project_filter),\n+\t\t              -class => $feed_class}, \"OPML\") . \" \";\n+\t\tprint $cgi->a({-href => href(project=>undef, action=>\"project_index\",\n+\t\t                             project_filter => $project_filter),\n+\t\t              -class => $feed_class}, \"TXT\") . \"\\n\";\n \t} else {\n \t\tprint $cgi->a({-href => href(project=>undef, action=>\"opml\"),\n \t\t              -class => $feed_class}, \"OPML\") . \" \";\n@@ -5979,7 +5997,7 @@ sub git_project_list {\n \t\tdie_error(400, \"Unknown order parameter\");\n \t}\n \n-\tmy @list = git_get_projects_list();\n+\tmy @list = git_get_projects_list($project_filter);\n \tif (!@list) {\n \t\tdie_error(404, \"No projects found\");\n \t}\n@@ -6018,7 +6036,7 @@ sub git_forks {\n }\n \n sub git_project_index {\n-\tmy @projects = git_get_projects_list();\n+\tmy @projects = git_get_projects_list($project_filter);\n \tif (!@projects) {\n \t\tdie_error(404, \"No projects found\");\n \t}\n@@ -7855,7 +7873,7 @@ sub git_atom {\n }\n \n sub git_opml {\n-\tmy @list = git_get_projects_list();\n+\tmy @list = git_get_projects_list($project_filter);\n \tif (!@list) {\n \t\tdie_error(404, \"No projects found\");\n \t}\n-- \n1.7.8.3\n"},{"id":"183206","messageId":"m31uqkepx6.fsf@localhost.localdomain","threadId":"29452","inReplyTo":"20120126144517.GA4229@server.brlink.eu","subject":"Re: [PATCH] gitweb: add pf= to limit project list to a subdirectory","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-01-27T22:33:10Z","receivedAt":"2012-01-27T22:33:10Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Bernhard R. Link\" <brl+list+git@mail.brlink.eu> writes:\n\n> This commit changes the project listings (project_list, project_index\n> and opml) to limit the output to only projects in a subdirectory if the\n> new optional parameter ?pf=directory name is used.\n\nCould you explain why you want this feature, and why for example\nproject search just does not cut it?\n \n> It uses the infrastructure already there for 'forks' (which also filters\n> projects but needs a project called like the filter directory to work).\n\nIt is not entirely clear for me that what you mean here is (I think)\nthat using\n\n  git_get_projects_list($project_filter);\n\njust works thanks to forks filtering infrastructure.\n\n> This feature is disabled if strict_export is used and there is no\n> projects_list to avoid showing more than intended.\n> Without strict_export enabled this change should not show any projects\n> one could not get details from anyway. So if the validate_pathname\n> checks are not sufficient this would at most make it easier to get a\n> list of viewable content.\n\nI don't wuite understand this reasoning.  Why project filtering is\ndisabled with strict_export?  It should just filter, regardless if\nproject are from scanning $project_filter subdirectory, or filtering\nout project names from $projects_list file that do not begin with\n$project_filter prefix.\n \n> Reusing $project instead of adding a new parameter would have been\n> nicer from a UI point-of-view (including PATH_INFO support) but\n> complicate the $project validating code that is currently being\n> used to ensure nothing is exported that should not be viewable.\n\nThat is I think quite reasonable.\n \n> Signed-off-by: Bernhard R. Link <brlink@debian.org>\n> \n> ---\n> As most parameters are not documented in documentation/gitweb.txt,\n> I did not add documentation for this one either.\n\nOn the other hand IIRC getting list of projects is quite well\ndocumented in gitweb manpage (or at least it should be).\n \n[...]\n> @@ -3962,6 +3973,13 @@ sub git_footer_html {\n>  \t\t\t              -class => $feed_class}, $format).\"\\n\";\n>  \t\t}\n>  \n> +\t} elsif (defined $project_filter) {\n> +\t\tprint $cgi->a({-href => href(project=>undef, action=>\"opml\",\n> +\t\t                             project_filter => $project_filter),\n> +\t\t              -class => $feed_class}, \"OPML\") . \" \";\n> +\t\tprint $cgi->a({-href => href(project=>undef, action=>\"project_index\",\n> +\t\t                             project_filter => $project_filter),\n> +\t\t              -class => $feed_class}, \"TXT\") . \"\\n\";\n>  \t} else {\n>  \t\tprint $cgi->a({-href => href(project=>undef, action=>\"opml\"),\n>  \t\t              -class => $feed_class}, \"OPML\") . \" \";\n\nI wonder if perhaps a better solution wouldn't be to use -replay=>1 in\ngenerating projects list in other formats (OPML and TXT).\n\n> @@ -5979,7 +5997,7 @@ sub git_project_list {\n>  \t\tdie_error(400, \"Unknown order parameter\");\n>  \t}\n>  \n> -\tmy @list = git_get_projects_list();\n> +\tmy @list = git_get_projects_list($project_filter);\n>  \tif (!@list) {\n>  \t\tdie_error(404, \"No projects found\");\n>  \t}\n> @@ -6018,7 +6036,7 @@ sub git_forks {\n>  }\n>  \n>  sub git_project_index {\n> -\tmy @projects = git_get_projects_list();\n> +\tmy @projects = git_get_projects_list($project_filter);\n>  \tif (!@projects) {\n>  \t\tdie_error(404, \"No projects found\");\n>  \t}\n> @@ -7855,7 +7873,7 @@ sub git_atom {\n>  }\n>  \n>  sub git_opml {\n> -\tmy @list = git_get_projects_list();\n> +\tmy @list = git_get_projects_list($project_filter);\n>  \tif (!@list) {\n>  \t\tdie_error(404, \"No projects found\");\n>  \t}\n\nNice!\n\n-- \nJakub Narebski\n"},{"id":"183211","messageId":"20120127235330.GA2718@server.brlink.eu","threadId":"29452","inReplyTo":"m31uqkepx6.fsf@localhost.localdomain","subject":"Re: [PATCH] gitweb: add pf= to limit project list to a subdirectory","fromName":"Bernhard R. Link","fromEmail":"brl+list+git@mail.brlink.eu","sentAt":"2012-01-27T23:53:32Z","receivedAt":"2012-01-27T23:53:32Z","isPatch":true,"sender":{"key":"brl+list+git@mail.brlink.eu","avatar":null},"body":"* Jakub Narebski <jnareb@gmail.com> [120127 23:33]:\n> > This commit changes the project listings (project_list, project_index\n> > and opml) to limit the output to only projects in a subdirectory if the\n> > new optional parameter ?pf=directory name is used.\n>\n> Could you explain why you want this feature, and why for example\n> project search just does not cut it?\n\nThe project list takes often a very long time and searching in that list\ntakes the same time (and would also show projects not starting with the\ntext).\n\nI'd for example like to be able to place a link to all projects shown\nat http://anonscm.debian.org/gitweb/ which are below mirrorer/ and get\na not having to wait for description information being extracted for all\nthe other projects.\n\n> > It uses the infrastructure already there for 'forks' (which also filters\n> > projects but needs a project called like the filter directory to work).\n> \n> It is not entirely clear for me that what you mean here is (I think)\n> that using\n> \n>   git_get_projects_list($project_filter);\n> \n> just works thanks to forks filtering infrastructure.\n\nYes, it uses the optional git_get_projects_list argument which is\ncurrently only used by action=forks.\n\n> > This feature is disabled if strict_export is used and there is no\n> > projects_list to avoid showing more than intended.\n> > Without strict_export enabled this change should not show any projects\n> > one could not get details from anyway. So if the validate_pathname\n> > checks are not sufficient this would at most make it easier to get a\n> > list of viewable content.\n> \n> I don't wuite understand this reasoning.  Why project filtering is\n> disabled with strict_export?  It should just filter, regardless if\n> project are from scanning $project_filter subdirectory, or filtering\n> out project names from $projects_list file that do not begin with\n> $project_filter prefix.\n\nstrict_export is a security switch to make sure that no unintended\ninformation is exported. Without a project_list all that strict_export\nensures is that there is no way to escape the project_root by giving\nsome path to a project outside that is not catched by the simple check\nagainst /./ and /../. As the new code would allow a way around this\ncheck, I think the sane thing is to simply disable this new feature in\ncase of this paranoid check being activated. (And reporting an error\nmessage if it is used).\n\n> > ---\n> > As most parameters are not documented in documentation/gitweb.txt,\n> > I did not add documentation for this one either.\n>\n> On the other hand IIRC getting list of projects is quite well\n> documented in gitweb manpage (or at least it should be).\n\nIn Documentation/gitweb.txt there is only a list of possible actions, but no\ndocumentation of any of the other arguments. (none of the order argument\nto project_list nor anything else). If actions like blob_plain do list\nessential arguments like f= then giving this option special rooms does\nnot seem to fit very well with the rest.\n\n>  \n> [...]\n> > @@ -3962,6 +3973,13 @@ sub git_footer_html {\n> >  \t\t\t              -class => $feed_class}, $format).\"\\n\";\n> >  \t\t}\n> >  \n> > +\t} elsif (defined $project_filter) {\n> > +\t\tprint $cgi->a({-href => href(project=>undef, action=>\"opml\",\n> > +\t\t                             project_filter => $project_filter),\n> > +\t\t              -class => $feed_class}, \"OPML\") . \" \";\n> > +\t\tprint $cgi->a({-href => href(project=>undef, action=>\"project_index\",\n> > +\t\t                             project_filter => $project_filter),\n> > +\t\t              -class => $feed_class}, \"TXT\") . \"\\n\";\n> >  \t} else {\n> >  \t\tprint $cgi->a({-href => href(project=>undef, action=>\"opml\"),\n> >  \t\t              -class => $feed_class}, \"OPML\") . \" \";\n> \n> I wonder if perhaps a better solution wouldn't be to use -replay=>1 in\n> generating projects list in other formats (OPML and TXT).\n\nWouldn't that also replay options like \"order\"?\n\n        Bernhard R. Link\n"},{"id":"183221","messageId":"201201281553.29387.jnareb@gmail.com","threadId":"29452","inReplyTo":"20120127235330.GA2718@server.brlink.eu","subject":"Re: [PATCH] gitweb: add pf= to limit project list to a subdirectory","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-01-28T14:53:28Z","receivedAt":"2012-01-28T14:53:28Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 28 Jan 2012, Bernhard R. Link wrote:\n> * Jakub Narebski <jnareb@gmail.com> [120127 23:33]:\n\n> > > This commit changes the project listings (project_list, project_index\n> > > and opml) to limit the output to only projects in a subdirectory if the\n> > > new optional parameter ?pf=directory name is used.\n> >\n> > Could you explain why you want this feature, and why for example\n> > project search just does not cut it?\n> \n> The project list takes often a very long time and searching in that list\n> takes the same time (and would also show projects not starting with the\n> text).\n\nThere are at least two ways to speed up getting projects list page.\n\n\nFirst is to limit number of projects shown, like e.g. http://repo.or.cz\nwhich shows only search form and tag cloud, but no projects, or at least\npaginate (divide into pages of e.g. 100 projects) list of projects.\n\nI have some patches improving projects list and searching projects, \nincluding slight speedup to search result generation and project list\npagination in my StGit stack.  I'll clean them up and (re)send them to\ngit mailing list for discussion.\n\n\nSecond solution would be to finally add caching support to gitweb,\neither on the level of caching git command output like Lea Wiemann\nwork from GSoC2008, or caching intermediate Perl data structures\nused by gitweb like in old patches by Petr 'Pasky' Baudis (though only\nfor projects list page), or caching of final HTML output like in\nhttp://git.kernel.org fork of gitweb.\n\nThere is some work in progress that I have in gitweb/cache branch and\nin gitweb/cache-kernel* branches in my repository (either on\nhttp://github.com/jnareb/git or http://repo.or.cz/w/git/jnareb-git.git).\n\nThe problem with cleaning it up to the form suitable for inclusion is\nthat it is quite a bit of code, and it very much requires splitting gitweb.\nSplitting gitweb in turn requires reworking of current hacky \"longjump\"\nbased (non-local goto) error handling into exception based error handling.\nThat in turn would be best handled using non-core CPAN modules, namely\nTry::Tiny and HTTP::Exception or at least Exception::Class.  For that\nwe need I think a way of bundling requirements with gitweb in inc/ \na la Module::Install.\n\nEhhh...\n\n> I'd for example like to be able to place a link to all projects shown\n> at http://anonscm.debian.org/gitweb/ which are below mirrorer/ and get\n> a not having to wait for description information being extracted for all\n> the other projects.\n\nI would prefer instead of introducing yet another arbitrary parameter\nextend project searching, so that you can specify that you want to\nsearch project names only (IIRC I have a patch for that, or beginnings\nof one, in my StGit stack), and use prefix search by the way of regexp\nsearch.\n\nSo\n\n  pf=mirrorer/\n\nwould be\n\n  s=^mirrorer/;sr=1;st=project_name\n \n> > > It uses the infrastructure already there for 'forks' (which also filters\n> > > projects but needs a project called like the filter directory to work).\n> > \n> > It is not entirely clear for me that what you mean here is (I think)\n> > that using\n> > \n> >   git_get_projects_list($project_filter);\n> > \n> > just works thanks to forks filtering infrastructure.\n> \n> Yes, it uses the optional git_get_projects_list argument which is\n> currently only used by action=forks.\n\nThis needs to be stated more clearly in the commit message.\n \n> > > This feature is disabled if strict_export is used and there is no\n> > > projects_list to avoid showing more than intended.\n> > > Without strict_export enabled this change should not show any projects\n> > > one could not get details from anyway. So if the validate_pathname\n> > > checks are not sufficient this would at most make it easier to get a\n> > > list of viewable content.\n> > \n> > I don't quite understand this reasoning.  Why project filtering is\n> > disabled with strict_export?  It should just filter, regardless if\n> > project are from scanning $project_filter subdirectory, or filtering\n> > out project names from $projects_list file that do not begin with\n> > $project_filter prefix.\n> \n> strict_export is a security switch to make sure that no unintended\n> information is exported. Without a project_list all that strict_export\n> ensures is that there is no way to escape the project_root by giving\n> some path to a project outside that is not catched by the simple check\n> against /./ and /../. As the new code would allow a way around this\n> check, I think the sane thing is to simply disable this new feature in\n> case of this paranoid check being activated. (And reporting an error\n> message if it is used).\n\nHmmm... I think this new feature can be made compatible with strict export...\nif it is not replaced by search extension, as I have proposed above.\n\n> > > ---\n> > > As most parameters are not documented in documentation/gitweb.txt,\n> > > I did not add documentation for this one either.\n> >\n> > On the other hand IIRC getting list of projects is quite well\n> > documented in gitweb manpage (or at least it should be).\n> \n> In Documentation/gitweb.txt there is only a list of possible actions, but no\n> documentation of any of the other arguments. (none of the order argument\n> to project_list nor anything else). If actions like blob_plain do list\n> essential arguments like f= then giving this option special rooms does\n> not seem to fit very well with the rest.\n\nI was thinking about \"Controlling access to git repositories\" section in\nDocumentation/gitweb.txt, but after closer examination I think it wouldn't\nfit there.\n\n> >  \n> > [...]\n> > > @@ -3962,6 +3973,13 @@ sub git_footer_html {\n> > >  \t\t\t              -class => $feed_class}, $format).\"\\n\";\n> > >  \t\t}\n> > >  \n> > > +\t} elsif (defined $project_filter) {\n> > > +\t\tprint $cgi->a({-href => href(project=>undef, action=>\"opml\",\n> > > +\t\t                             project_filter => $project_filter),\n> > > +\t\t              -class => $feed_class}, \"OPML\") . \" \";\n> > > +\t\tprint $cgi->a({-href => href(project=>undef, action=>\"project_index\",\n> > > +\t\t                             project_filter => $project_filter),\n> > > +\t\t              -class => $feed_class}, \"TXT\") . \"\\n\";\n> > >  \t} else {\n> > >  \t\tprint $cgi->a({-href => href(project=>undef, action=>\"opml\"),\n> > >  \t\t              -class => $feed_class}, \"OPML\") . \" \";\n> > \n> > I wonder if perhaps a better solution wouldn't be to use -replay=>1 in\n> > generating projects list in other formats (OPML and TXT).\n> \n> Wouldn't that also replay options like \"order\"?\n\nRight.  My mistake.\n\n\nAnyway\n\n+\t\tprint $cgi->a({-href => href(project=>undef, action=>\"opml\",\n+\t\t                             project_filter => $project_filter),\n+\t\t              -class => $feed_class}, \"OPML\") . \" \";\n+\t\tprint $cgi->a({-href => href(project=>undef, action=>\"project_index\",\n+\t\t                             project_filter => $project_filter),\n+\t\t              -class => $feed_class}, \"TXT\") . \"\\n\";\n\nwould do the right thing because of the way href() works when passed\nkey-value pair with undefined key.\n\nIn other words there is no need for conditional; just add \n\n   project_filter => $project_filter\n\nand href() would do the right thing.\n-- \nJakub Narebski\nPoland\n"},{"id":"183220","messageId":"20120128153750.GB3397@server.brlink.eu","threadId":"29452","inReplyTo":"201201281553.29387.jnareb@gmail.com","subject":"Re: [PATCH] gitweb: add pf= to limit project list to a subdirectory","fromName":"Bernhard R. Link","fromEmail":"brl+list+git@mail.brlink.eu","sentAt":"2012-01-28T15:37:50Z","receivedAt":"2012-01-28T15:37:50Z","isPatch":true,"sender":{"key":"brl+list+git@mail.brlink.eu","avatar":null},"body":"* Jakub Narebski <jnareb@gmail.com> [120128 15:53]:\n> On Sat, 28 Jan 2012, Bernhard R. Link wrote:\n> > The project list takes often a very long time and searching in that list\n> > takes the same time (and would also show projects not starting with the\n> > text).\n>\n> There are at least two ways to speed up getting projects list page.\n\nThere are other ways, but they are both limited and quite backward:\nInstead of showing me the information I want (what is in that\ndirectory), I guess to search in the larger pool of information needing\nall sort of half-working tricks causing all kinds of other problems\nworking around the issue that much more information never used must be\ncollected first.\n\nSubversion's ViewVC for example only shows what is in some directory\ndirectory and available subdirectories. (That of course has the\ndisadvantage to make it harder to find a project one does not know\nthe subdirectory it is in, but why shouldn't gitweb offer the best of\nboth worlds?)\n\n> First is to limit number of projects shown, like e.g. http://repo.or.cz\n> which shows only search form and tag cloud, but no projects, or at least\n> paginate (divide into pages of e.g. 100 projects) list of projects.\n\nBut a page showing all projects (as long as it is possible) is something\nI'd quite miss if it is gone. What I want is some way to have that and\nto also be able to look at some subset interesting to me directly in an\neffective way.\n\n> Second solution would be to finally add caching support to gitweb,\n\nBut caching also means new projects or changes will take some time to\nshow up. And again it would not be a solution to by original problem.\n(Showing effectively what is in some directory).\n\n> > I'd for example like to be able to place a link to all projects shown\n> > at http://anonscm.debian.org/gitweb/ which are below mirrorer/ and get\n> > a not having to wait for description information being extracted for all\n> > the other projects.\n>\n> I would prefer instead of introducing yet another arbitrary parameter\n> extend project searching, so that you can specify that you want to\n> search project names only (IIRC I have a patch for that, or beginnings\n> of one, in my StGit stack), and use prefix search by the way of regexp\n> search.\n\n> So\n>\n>   pf=mirrorer/\n>\n> would be\n>\n>   s=^mirrorer/;sr=1;st=project_name\n\nThat might be a workaround, but still need to look at quite some amount\nof unecessary data (i.e. it would need to run at least as long as a\nhttp://anonscm.debian.org/gitweb/?a=project_index would not to load,\nwouldn't it?)\n\n        Bernhard R. Link\n"},{"id":"183222","messageId":"201201281703.07313.jnareb@gmail.com","threadId":"29452","inReplyTo":"20120128153750.GB3397@server.brlink.eu","subject":"Re: [PATCH] gitweb: add pf= to limit project list to a subdirectory","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-01-28T16:03:06Z","receivedAt":"2012-01-28T16:03:06Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 28 Jan 2012, Bernhard R. Link wrote:\n> * Jakub Narebski <jnareb@gmail.com> [120128 15:53]:\n> > On Sat, 28 Jan 2012, Bernhard R. Link wrote:\n\n> > > The project list takes often a very long time and searching in that list\n> > > takes the same time (and would also show projects not starting with the\n> > > text).\n> >\n> > There are at least two ways to speed up getting projects list page.\n> \n> There are other ways, but they are both limited and quite backward:\n> Instead of showing me the information I want (what is in that\n> directory), I guess to search in the larger pool of information needing\n> all sort of half-working tricks causing all kinds of other problems\n> working around the issue that much more information never used must be\n> collected first.\n> \n> Subversion's ViewVC for example only shows what is in some directory\n> directory and available subdirectories. (That of course has the\n> disadvantage to make it harder to find a project one does not know\n> the subdirectory it is in, but why shouldn't gitweb offer the best of\n> both worlds?)\n\nWell, ViewVC follows Subversion concepts... including broken-by-design\nbranching by copying ;-)\n\n\nAnyway, I think I am getting convinced that supporting project filtering\nby subdirectory, in a way similar to existing support for forks (and reusing\nit implementation) could be a good idea.  \n\nThe one serious disadvantage of \"pf=\" is that it is not solution for a\nfaster gitweb homepage.  It works _only_ when you have pf=subdirectory/\nlink.\n\nAnd I'd rather it worked with strict export, correctly and safely,\nif \"pf=\" is to be included in gitweb.\n \n> > First is to limit number of projects shown, like e.g. http://repo.or.cz\n> > which shows only search form and tag cloud, but no projects, or at least\n> > paginate (divide into pages of e.g. 100 projects) list of projects.\n> \n> But a page showing all projects (as long as it is possible) is something\n> I'd quite miss if it is gone. What I want is some way to have that and\n> to also be able to look at some subset interesting to me directly in an\n> effective way.\n\nThe http://repo.or.cz homepage has 'Show all projects' link, but it is\nat explicit request. \n\n> > Second solution would be to finally add caching support to gitweb,\n> \n> But caching also means new projects or changes will take some time to\n> show up. And again it would not be a solution to by original problem.\n> (Showing effectively what is in some directory).\n\nWell, it would solve \"The project list takes often a very long time\"\npart of your problem.  Though very large list of projects can cause\nperformance problems rendering on client side, I guess...\n \n> > > I'd for example like to be able to place a link to all projects shown\n> > > at http://anonscm.debian.org/gitweb/ which are below mirrorer/ and get\n> > > a not having to wait for description information being extracted for all\n> > > the other projects.\n> >\n> > I would prefer instead of introducing yet another arbitrary parameter\n> > extend project searching, so that you can specify that you want to\n> > search project names only (IIRC I have a patch for that, or beginnings\n> > of one, in my StGit stack), and use prefix search by the way of regexp\n> > search.\n> >\n> > So\n> >\n> >   pf=mirrorer/\n> >\n> > would be\n> >\n> >   s=^mirrorer/;sr=1;st=project_name\n> \n> That might be a workaround, but still need to look at quite some amount\n> of unecessary data (i.e. it would need to run at least as long as a\n> http://anonscm.debian.org/gitweb/?a=project_index would not to load,\n> wouldn't it?)\n\nNot with 'gitweb: Faster project search' from this series of commits\n\n  # gitweb: Allow underscore in $searchtype ('st')\n  # gitweb: Improve projects search form\n  # gitweb: Option for filling only specified info in fill_project_list_info\n  # gitweb: Faster project search\n  # gitweb: Highlight matched part of project name when searching projects\n  # gitweb: Highlight matched part of project description when searching projects\n\nwhich does not search for description nor check for latest changes in\nrepository for repositories it doesn't show.\n\n-- \nJakub Narebski\nPoland\n"}]}