Re: [PATCH] gitweb: add pf= to limit project list to a subdirectory
flat view
From: Jakub Narebski <hidden>
Date: 2016-06-15 22:52:52
"Bernhard R. Link" [off-list ref] writes:
This commit changes the project listings (project_list, project_index and opml) to limit the output to only projects in a subdirectory if the new optional parameter ?pf=directory name is used.
Could you explain why you want this feature, and why for example project search just does not cut it?
It uses the infrastructure already there for 'forks' (which also filters projects but needs a project called like the filter directory to work).
It is not entirely clear for me that what you mean here is (I think) that using git_get_projects_list($project_filter); just works thanks to forks filtering infrastructure.
This feature is disabled if strict_export is used and there is no projects_list to avoid showing more than intended. Without strict_export enabled this change should not show any projects one could not get details from anyway. So if the validate_pathname checks are not sufficient this would at most make it easier to get a list of viewable content.
I don't wuite understand this reasoning. Why project filtering is disabled with strict_export? It should just filter, regardless if project are from scanning $project_filter subdirectory, or filtering out project names from $projects_list file that do not begin with $project_filter prefix.
Reusing $project instead of adding a new parameter would have been nicer from a UI point-of-view (including PATH_INFO support) but complicate the $project validating code that is currently being used to ensure nothing is exported that should not be viewable.
That is I think quite reasonable.
Signed-off-by: Bernhard R. Link <redacted> --- As most parameters are not documented in documentation/gitweb.txt, I did not add documentation for this one either.
On the other hand IIRC getting list of projects is quite well documented in gitweb manpage (or at least it should be). [...]
quoted hunk ↗ jump to hunk
@@ -3962,6 +3973,13 @@ sub git_footer_html { -class => $feed_class}, $format)."\n"; } + } elsif (defined $project_filter) { + print $cgi->a({-href => href(project=>undef, action=>"opml", + project_filter => $project_filter), + -class => $feed_class}, "OPML") . " "; + print $cgi->a({-href => href(project=>undef, action=>"project_index", + project_filter => $project_filter), + -class => $feed_class}, "TXT") . "\n"; } else { print $cgi->a({-href => href(project=>undef, action=>"opml"), -class => $feed_class}, "OPML") . " ";
I wonder if perhaps a better solution wouldn't be to use -replay=>1 in generating projects list in other formats (OPML and TXT).
quoted hunk ↗ jump to hunk
@@ -5979,7 +5997,7 @@ sub git_project_list { die_error(400, "Unknown order parameter"); } - my @list = git_get_projects_list(); + my @list = git_get_projects_list($project_filter); if (!@list) { die_error(404, "No projects found"); }@@ -6018,7 +6036,7 @@ sub git_forks { } sub git_project_index { - my @projects = git_get_projects_list(); + my @projects = git_get_projects_list($project_filter); if (!@projects) { die_error(404, "No projects found"); }@@ -7855,7 +7873,7 @@ sub git_atom { } sub git_opml { - my @list = git_get_projects_list(); + my @list = git_get_projects_list($project_filter); if (!@list) { die_error(404, "No projects found"); }
Nice! -- Jakub Narebski