Re: [PATCH] gitweb: add pf= to limit project list to a subdirectory
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Jan 27, 2012, 22:33 UTC
- Message-ID
- <m31uqkepx6.fsf@localhost.localdomain>
- In-Reply-To
- <20120126144517.GA4229@server.brlink.eu>
"Bernhard R. Link" <brl+list+git@mail.brlink.eu> 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.
Show 6 quoted lines
> 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.
Show 5 quoted lines
> Signed-off-by: Bernhard R. Link <brlink@debian.org> > > --- > 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). [...]
Show 14 quoted lines
> @@ -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).
Show 27 quoted lines
> @@ -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