Re: [PATCH v3 3/3] gitweb: Optional grouping of projects by category

On Fri, 12 Dec 2008, Sébastien Cevey wrote:

At Fri, 12 Dec 2008 03:03:55 +0100, Jakub Narebski wrote:

quoted

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