Re: [PATCH v2] gitweb: Optional grouping of projects by category

From: Jakub Narebski <jnareb@gmail.com>
Date: Dec 3, 2008, 23:12 UTC
Message-ID: <200812040012.30885.jnareb@gmail.com>
In-Reply-To: <7viqq0c1pg.fsf@gitster.siamese.dyndns.org>

On Wed, 3 Dec 2008, Junio C Hamano wrote:

> Sébastien Cevey <seb@cine7.net> writes:

Show 14 quoted lines

> > 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.

Well, this way of sorting, i.e. keeping order of categories constant, and changing order _within_ categories has the advantage that changing order (the column we sort by) doesn't change page layout, i.e. in this case doesn't change categories layout.

It means that if we had:

  project1
  project2
  [category A]
  A/pr1
  A/pr2
  [category B]
  B/pr1
  B/pr2
  B/pr3

when sorting by project name, we will have similarly looking

  project2
  project1
  [category A]
  A/pr1
  A/pr2
  [category B]
  B/pr3
  B/pr1
  B/pr2

for example if we order by age (not shown here)

Show 10 quoted lines

> > - 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.

Currently the only selection is by tag, but lets assume that we have some page length limit and only first N projects (first N in given sort order) are shown.

If we have selection by tag, only those categories that have at least one project tagged with selected tag, and only projects with given tag would be shown. If we have page limit on projects list page, and we sort for example by age, then only categories with freshest projects will be shown.

At least it is how I understand it...

> While I think both the introduction of "git_get_project_config_or_file"

Errr... I think it is git_get_file_or_project_config ;-))))

Show 6 quoted lines

> 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.

 
I agree, especially the second part, as adding print_project_rows patch
looks harder than it actually is.

-- 
Jakub Narebski
Poland