Re: [PATCH 1/2] gitweb: allow access to forks with strict_export

From: Matt McCutchen <matt@mattmccutchen.net>
Date: Dec 14, 2008, 01:51 UTC
Message-ID: <1229219475.3360.51.camel@mattlaptop2.local>
In-Reply-To: <7vr64b4sib.fsf@gitster.siamese.dyndns.org>

On Sat, 2008-12-13 at 14:31 -0800, Junio C Hamano wrote:

Show 27 quoted lines

> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > Matt McCutchen <matt@mattmccutchen.net> writes:
> >
> > CC-ed Petr Baudis, author of forks support in gitweb.
> >
> >> git_get_projects_list excludes forks in order to unclutter the main
> >> project list, but this caused the strict_export check, which also relies
> >> on git_get_project_list, to incorrectly fail for forks.  This patch adds
> >> an argument so git_get_projects_list knows when it is being called for a
> >> strict_export check (as opposed to a user-visible project list) and
> >> doesn't exclude the forks.
> >>
> >> Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
> >
> > Looks good for me.
> 
> That sounds like a broken API to me.
> 
> At least, please have the decency to not call the extra parameter "for
> strict export".  I would understand it if the extra parameter is called
> "toplevel_only" (or its negation, "include_forks").
> 
> IOW, don't name a parameter after the name of one caller that happens to
> want an unspecified special semantics, without saying what that special
> semantics is.  Instead, name it after the special semantics that the
> argument triggers.

I disagree. The parameter is really "include forks (if there is such a concept under the current config)", and with my second patch, it becomes "include hidden projects" too. That's really unwieldy.

In my view, the parameter makes the distinction between generating a filtered list for user consumption and a list of everything for a strict_export check. The particular semantics it activates may evolve as gitweb does (case in point: my second patch). The current semantics can be described in a comment on git_get_projects_list.

Granted, there may be a better name for the parameter than $for_strict_export. How about $include_all?

-- 
Matt