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