"Bernhard R. Link" <brl+list+git@xxxxxxxxxxxxxx> 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@xxxxxxxxxx>
>
> ---
> 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
--
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