git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jakub Narebski <jnareb@gmail.com>
Date
Dec 12, 2008, 09:26 UTC
Message-ID
<200812121026.07694.jnareb@gmail.com>
In-Reply-To
<87y6ymxf4k.wl%seb@cine7.net>
On Fri, 12 Dec 2008, Sébastien Cevey wrote:
Show 8 quoted lines
> 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.

Show 34 quoted lines
> 
> 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.
[...]
Show 22 quoted lines
> 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
Previous: Sébastien CeveyNext: Jakub Narebski
Message 20 of 24 in “gitweb: Optional grouping of projects by category”
  1. gitweb: Optional grouping of projects by categorySebastien Cevey, Dec 2, 2008
  2. Jakub NarebskiDec 2, 2008
  3. gitweb: Optional grouping of projects by categorySébastien Cevey, Dec 3, 2008
  4. Junio C HamanoDec 3, 2008
  5. Jakub NarebskiDec 3, 2008
  6. 0/3 gitweb: Optional grouping of projects by categorySébastien Cevey, Dec 4, 2008
  7. Junio C HamanoDec 4, 2008
  8. 1/3 gitweb: Modularized git_get_project_description to be more genericSébastien Cevey, Dec 4, 2008
  9. 2/3 gitweb: Split git_project_list_body in two functionsSébastien Cevey, Dec 4, 2008
  10. 3/3 gitweb: Optional grouping of projects by categorySébastien Cevey, Dec 4, 2008
  11. Junio C HamanoDec 4, 2008
  12. Jakub NarebskiDec 5, 2008
  13. Sébastien CeveyDec 5, 2008
  14. Jakub NarebskiDec 5, 2008
  15. Sébastien CeveyDec 11, 2008
  16. Jakub NarebskiDec 12, 2008
  17. Sébastien CeveyDec 12, 2008
  18. Jakub NarebskiDec 12, 2008
  19. Sébastien CeveyDec 12, 2008
  20. Jakub NarebskiDec 12, 2008
  21. Jakub NarebskiDec 5, 2008
  22. Jakub NarebskiDec 5, 2008
  23. Sébastien CeveyDec 3, 2008
  24. Junio C HamanoDec 3, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.