git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: "Sébastien Cevey" <seb@cine7.net>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Petr Baudis <pasky@suse.cz>,
	Gustavo Sverzut Barbieri <barbieri@profusion.mobi>
Subject: Re: [PATCH v3 3/3] gitweb: Optional grouping of projects by category
Date: Fri, 12 Dec 2008 10:26:06 +0100	[thread overview]
Message-ID: <200812121026.07694.jnareb@gmail.com> (raw)
In-Reply-To: <87y6ymxf4k.wl%seb@cine7.net>

On Fri, 12 Dec 2008, Sébastien Cevey wrote:
> At Fri, 12 Dec 2008 03:03:55 +0100, Jakub Narebski wrote:
> 
> > And no, we don't need to sort by categories first.  Let me explain
> > in more detail a bit.
> 
> Thanks for the detailed explanation, I understand your preference.
> But as you said, it's a bit arbitrary, I think none is completely
> obvious.

First, I feel a bit bad for derailing this patch. Currently gitweb
does not do pagination of projects list; it is not even possible in
a sane way with current way project searching/selecting is implemented.
So the whole build_projlist_by_category() respecting $from and $to is
moot point.

So if we don't use it, even if it is nice to have for the future, we
don't need to pay cost of extra stable sorting.

> 
> I don't really have a strong opinion about which is best, but just to
> illustrate what made me go for the solution B, let me show another
> example:
> 
> name / date / cat
> 1      2006    A
> 2      2003    B
> 3      2005    B
> 4      2003    A
> 5      2000    A
> 6      2008    C
> 7      2007    C
> 8      2001    B
> 9      2005    A
> 
> We then sort by name and split in pages of N=3 (sorted by cat on each
> page):
> 
> A:sort(name) split(max=3) subsort(cat)
>   1  2006  A     4  2003  A     9  2005  A
>   2  2003  B     5  2000  A     8  2001  B
>   3  2005  B     6  2008  C     7  2007  C
> 
> B:sort(cat) subsort(name) split(max=3)
>   1  2006  A     9  2005  A     8  2001  B
>   4  2003  A     2  2003  B     6  2008  C
>   5  2000  A     3  2005  B     7  2007  C
> 
> With B, we have the second top-entry (2) relegated to the second page,
> which might be surprising because we ordered by name.  But what I find
> weird about A is that because of the per-page category sorting, the
> "top-sorted entries at the top" isn't true either (page 3).  We have
> "reshuffled" the result of 'sort(name) split(max=3)' on each page.

[...]
> It's perhaps even more apparent if we sort by date:
> 
> A:sort(year) split(max=3) subsort(cat)
>   1  2006  A     9  2005  A     4  2003  A
>   6  2008  C     3  2005  B     5  2000  A
>   7  2007  C     2  2003  B     8  2001  B
> 
> B:sort(cat) subsort(year) split(max=4)
>   1  2006  A     4  2003  A     3  2005  B
>   9  2005  A     8  2001  B     7  2007  C
>   5  2000  A     2  2003  B     6  2008  C
> 
> It feels kind of unnatural that not only projects are not sorted by
> date on each page (they are inside categories), but moreover
> categories are spread over all pages.
> 
> 
> I guess it depends on your use case, and whether categories are
> important or known by the user.  I personally don't really care (I
> never split stuff into pages in the gitweb I use), so I can do a new
> version of my patch that does A if you prefer, just let me know.  I
> just wanted to clarify that both solutions sort of suck :-)

Well, with version A you can (I think) simply change

  foreach my $cat (sort keys %categories) {

to

  foreach my $cat (sort 
  	{ cmp_cat($projlist, \%categories, $oi, $a, $b) } keys %categories) {

to have the following output (see the difference on page 3)

A':sort(name) split(max=3) subsort(sort(cat,name))
  1  2006  A     4  2003  A     7  2007  C
  2  2003  B     5  2000  A     8  2001  B
  3  2005  B     6  2008  C     9  2005  A

where sort_cat might be something like (we took advantage that
categories in %categories have at least one project):

  sub cmp_cat {
  	my ($projlist, $cats, $oi, $a, $b) = @_;
  	my ($aa, $bb);
  	# projects in categories are sorted, so we can compare first
  	# project from a category to sort categories in given ordering
  	$aa = $projlist->{$cats->{$a}[0]};
  	$bb = $projlist->{$cats->{$b}[0]};
  	if ($oi->{'type'} eq 'str') {
		return $aa->{$oi->{'key'}} cmp $bb->{$oi->{'key'}};
	} else {
		return $aa->{$oi->{'key'}} <=> $bb->{$oi->{'key'}};
	}
  }

-- 
Jakub Narebski
Poland

  reply	other threads:[~2008-12-12  9:27 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
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 [this message]
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=200812121026.07694.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=barbieri@profusion.mobi \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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).