Re: [PATCH 1/2] gitweb: allow access to forks with strict_export
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Dec 13, 2008, 22:51 UTC
- Message-ID
- <200812132351.37420.jnareb@gmail.com>
- In-Reply-To
- <7vr64b4sib.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
Show 26 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.
Ahhh... true.
"no_hide" (currently "include_forks") allows us to _not_ passing this parameter in other places than project_in_list(); undef is falsy.
By the way, doesn't git_project_index and perhaps git_opml also need this parameter passed to git_get_projects_list?
Then patch subject would change...
-- Jakub Narebski Poland