On Sat, 2008-12-13 at 23:51 +0100, Jakub Narebski wrote: > "no_hide" (currently "include_forks") allows us to _not_ passing this > parameter in other places than project_in_list(); undef is falsy. Right. That's why I made the current parameter $for_strict_export (so only project_in_list passes it) rather than the negation. > By the way, doesn't git_project_index and perhaps git_opml also need > this parameter passed to git_get_projects_list? Yes, now that you mention it, I suppose they should show forks, though not hidden repositories. Then git_get_projects_list can be called in three different modes: include everything (project_in_list), include forks but not hidden (git_get_project_index and git_opml), or include neither forks nor hidden (git_project_list). Should we have two separate parameters to git_get_projects_list or a single three-valued one? That raises another point. I was going to change git_get_projects_list so that forks of a hidden project that are not themselves hidden appear on the parent project's page but not in the main project list. This way, users who know about the parent project can navigate to the fork, but the fork does not give away the existence of the parent project by appearing in the main list. Then I guess git_project_index and git_opml should omit forks of hidden projects, meaning that some fork-checking still has to take place with "include forks" on but "include hidden" off. This will make git_get_projects_list somewhat more complex but not unmanageably so, and I do think it's the behavior we want. I will send an updated patch. -- Matt -- 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
