From 55934ce4fe80574e76f495e3d19a6041be1e6dda Mon Sep 17 00:00:00 2001 From: "Kyle J. McKay" Date: Sat, 4 Apr 2015 14:57:37 -0700 Subject: [PATCH] t/frontpage/separate: re-create TopGit-controlled branch --- .topdeps | 2 +- .topmsg | 44 ++++++++++++++++++++++++++------------------ 2 files changed, 27 insertions(+), 19 deletions(-) rewrite .topmsg (88%) diff --git a/.topdeps b/.topdeps index d7025695e2..0c3e8ae999 100644 --- a/.topdeps +++ b/.topdeps @@ -1 +1 @@ -release +t/frontpage/ctags diff --git a/.topmsg b/.topmsg dissimilarity index 88% index d9175b5fcd..ed668edf1c 100644 --- a/.topmsg +++ b/.topmsg @@ -1,18 +1,26 @@ -Subject: [PATCH] gitweb: polish the content tags support - -This patch integrates the tag filtering CGI parameter into the framework -for parameter passing, dropping 'by_tag' and instead using query name 't' -and symbolic name 'ctag_filter'. Compatibility support for 'by_tag' query -name is retained. - -This means that content tag links are now created using $cgi->a() and -the href() method, and that they now point to the proper action; -project_list in case of global content tags, forks in case of per-fork -content tags. Also any other arguments like sorting order of projects -are replayed within the links. - -This patch also restores the ability to add tags if the ctags feature -is set to a POST action rather than a positive integer. - -Signed-off-by: Petr Baudis -Signed-off-by: Kyle J. McKay +Subject: [PATCH] gitweb: support for no project list on gitweb front page + +On very large sites like repo.or.cz (but maybe also git.debian.org, +git.kernel.org, etc.), it is desirable not to have the project list +on the front page since generating it is significant overhead and it +takes significant data transfer and load time for the user, who might +prefer to instead use the search form and possibly content tags to +navigate to the target project. A link to the full list of projects is +still available on the front page for users who wish to browse it. The +whole feature is turned off by default. + +The patch introduces a new config variable $frontpage_no_project_list, +by default 0 keeping the current behavior; if set to 1, no project list +will be shown, but all projects will be still scanned if ctags are +enabled; if set to 2, no project will be shown and no projects will +be scanned while showing the front page. The compromise value of 1 is +useful for sites where project scan time is not an issue or which +use additional project list caching patches. + +The patch furthermore modifies project_list action not to show the +index text, and introduces new default action frontpage which is by +default identical to old project_list action, but can be further +controlled by the $frontpage_no_project_list variable. + +Signed-off-by: Petr Baudis +Signed-off-by: Kyle J. McKay -- 2.11.4.GIT