From: Junio C Hamano <gitster@pobox.com>
To: "Sébastien Cevey" <seb@cine7.net>
Cc: Jakub Narebski <jnareb@gmail.com>,
git@vger.kernel.org, Petr Baudis <pasky@suse.cz>,
Gustavo Sverzut Barbieri <barbieri@profusion.mobi>
Subject: Re: [PATCH v2] gitweb: Optional grouping of projects by category
Date: Wed, 03 Dec 2008 14:51:07 -0800 [thread overview]
Message-ID: <7viqq0c1pg.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <87prk91got.wl%seb@cine7.net> (Sébastien Cevey's message of "Wed, 03 Dec 2008 15:22:58 +0100")
Sébastien Cevey <seb@cine7.net> 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.
next prev parent reply other threads:[~2008-12-03 22:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-02 15:04 [PATCH] gitweb: Optional grouping of projects by category Sebastien Cevey
2008-12-02 23:36 ` Jakub Narebski
2008-12-03 14:22 ` [PATCH v2] " Sébastien Cevey
2008-12-03 22:51 ` Junio C Hamano [this message]
2008-12-03 23:12 ` Jakub Narebski
2008-12-04 0:39 ` [PATCH v3 0/3] " Sébastien Cevey
2008-12-04 0:43 ` Junio C Hamano
2008-12-04 0:42 ` [PATCH v3 1/3] gitweb: Modularized git_get_project_description to be more generic Sébastien Cevey
2008-12-04 0:44 ` [PATCH v3 2/3] gitweb: Split git_project_list_body in two functions Sébastien Cevey
2008-12-04 0:46 ` [PATCH v3 3/3] gitweb: Optional grouping of projects by category Sébastien Cevey
2008-12-04 19:37 ` Junio C Hamano
2008-12-05 2:08 ` Jakub Narebski
2008-12-05 2:32 ` Sébastien Cevey
2008-12-05 10:45 ` Jakub Narebski
2008-12-11 23:34 ` Sébastien Cevey
2008-12-12 0:13 ` Jakub Narebski
2008-12-12 0:40 ` Sébastien Cevey
2008-12-12 2:03 ` Jakub Narebski
2008-12-12 3:10 ` Sébastien Cevey
2008-12-12 9:26 ` Jakub Narebski
2008-12-05 1:52 ` [PATCH v3 2/3] gitweb: Split git_project_list_body in two functions Jakub Narebski
2008-12-05 1:38 ` [PATCH v3 1/3] gitweb: Modularized git_get_project_description to be more generic Jakub Narebski
2008-12-03 14:29 ` [PATCH] gitweb: Optional grouping of projects by category Sébastien Cevey
2008-12-03 21:14 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7viqq0c1pg.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=barbieri@profusion.mobi \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=pasky@suse.cz \
--cc=seb@cine7.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).