On Sat, 28 Jan 2012, Bernhard R. Link wrote: > * Jakub Narebski <jnareb@xxxxxxxxx> [120128 15:53]: > > On Sat, 28 Jan 2012, Bernhard R. Link wrote: > > > The project list takes often a very long time and searching in that list > > > takes the same time (and would also show projects not starting with the > > > text). > > > > There are at least two ways to speed up getting projects list page. > > There are other ways, but they are both limited and quite backward: > Instead of showing me the information I want (what is in that > directory), I guess to search in the larger pool of information needing > all sort of half-working tricks causing all kinds of other problems > working around the issue that much more information never used must be > collected first. > > Subversion's ViewVC for example only shows what is in some directory > directory and available subdirectories. (That of course has the > disadvantage to make it harder to find a project one does not know > the subdirectory it is in, but why shouldn't gitweb offer the best of > both worlds?) Well, ViewVC follows Subversion concepts... including broken-by-design branching by copying ;-) Anyway, I think I am getting convinced that supporting project filtering by subdirectory, in a way similar to existing support for forks (and reusing it implementation) could be a good idea. The one serious disadvantage of "pf=" is that it is not solution for a faster gitweb homepage. It works _only_ when you have pf=subdirectory/ link. And I'd rather it worked with strict export, correctly and safely, if "pf=" is to be included in gitweb. > > First is to limit number of projects shown, like e.g. http://repo.or.cz > > which shows only search form and tag cloud, but no projects, or at least > > paginate (divide into pages of e.g. 100 projects) list of projects. > > But a page showing all projects (as long as it is possible) is something > I'd quite miss if it is gone. What I want is some way to have that and > to also be able to look at some subset interesting to me directly in an > effective way. The http://repo.or.cz homepage has 'Show all projects' link, but it is at explicit request. > > Second solution would be to finally add caching support to gitweb, > > But caching also means new projects or changes will take some time to > show up. And again it would not be a solution to by original problem. > (Showing effectively what is in some directory). Well, it would solve "The project list takes often a very long time" part of your problem. Though very large list of projects can cause performance problems rendering on client side, I guess... > > > I'd for example like to be able to place a link to all projects shown > > > at http://anonscm.debian.org/gitweb/ which are below mirrorer/ and get > > > a not having to wait for description information being extracted for all > > > the other projects. > > > > I would prefer instead of introducing yet another arbitrary parameter > > extend project searching, so that you can specify that you want to > > search project names only (IIRC I have a patch for that, or beginnings > > of one, in my StGit stack), and use prefix search by the way of regexp > > search. > > > > So > > > > pf=mirrorer/ > > > > would be > > > > s=^mirrorer/;sr=1;st=project_name > > That might be a workaround, but still need to look at quite some amount > of unecessary data (i.e. it would need to run at least as long as a > http://anonscm.debian.org/gitweb/?a=project_index would not to load, > wouldn't it?) Not with 'gitweb: Faster project search' from this series of commits # gitweb: Allow underscore in $searchtype ('st') # gitweb: Improve projects search form # gitweb: Option for filling only specified info in fill_project_list_info # gitweb: Faster project search # gitweb: Highlight matched part of project name when searching projects # gitweb: Highlight matched part of project description when searching projects which does not search for description nor check for latest changes in repository for repositories it doesn't show. -- Jakub Narebski Poland -- 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