Sébastien Cevey <seb@xxxxxxxxx> writes: > This adds the $projects_list_group_categories option which, if enabled, > will result in grouping projects by category on the project list page. > The category is specified for each project by the $GIT_DIR/category file > or the 'category' variable in its configuration file. By default, projects > are put in the $project_list_default_category category. > > Note: > - Categories are always sorted alphabetically, with projects in > each category sorted according to the globally selected $order. I am not sure if always sorting the categories alphabetically is a severe enough restriction, but if it was, you can use @project_list_categories array that disables the feature when empty and otherwise enumerates the categories in order. Just an idle thought. > - When displaying a subset of all the projects, only the categories with > projects in the chosen subset are displayed. Could you clarify this bit? It is not very clear to me how this subset selection happens. As far as I can see, the user does not choose the category to view, but lets the usual page limiting to decide at which project to start and stop placing on the page, and only show the ones in the same category as the one that happened to be the first on the page. While I think both the introduction of "git_get_project_config_or_file" which is a generalized interface usable between description and the new feature and the refactoring of project_list_body into a seprate function "print_project_rows" is a good idea, the patch would have been much easier to read if these preparatory refactoring steps (without any new feature) were done as a separate patch followed by the main patch to introduce the new feature. -- 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
