Re: [PATCH] gitweb: add pf= to limit project list to a subdirectory

[Jakub Narebski <jnareb@gmail.com>]

"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.

> 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 <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).
 
[...]
> @@ -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).

> @@ -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