Junio C Hamano wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: > > Matt McCutchen <matt@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx> >> >> 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 -- 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
