From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?S=E9bastien?= Cevey Subject: Re: [PATCH v3 3/3] gitweb: Optional grouping of projects by category Date: Fri, 12 Dec 2008 04:10:35 +0100 Message-ID: <87y6ymxf4k.wl%seb@cine7.net> References: <87wsei1uvp.wl%seb@cine7.net> <200812120113.47051.jnareb@gmail.com> <87zlj2xm35.wl%seb@cine7.net> <200812120303.56997.jnareb@gmail.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: git@vger.kernel.org, Junio C Hamano , Petr Baudis , Gustavo Sverzut Barbieri To: Jakub Narebski X-From: git-owner@vger.kernel.org Fri Dec 12 04:10:49 2008 Return-path: Envelope-to: gcvg-git-2@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1LAyQR-0001hC-U6 for gcvg-git-2@gmane.org; Fri, 12 Dec 2008 04:10:48 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757001AbYLLDJa convert rfc822-to-quoted-printable (ORCPT ); Thu, 11 Dec 2008 22:09:30 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757007AbYLLDJa (ORCPT ); Thu, 11 Dec 2008 22:09:30 -0500 Received: from smtp.nimag.net ([62.220.136.11]:60200 "EHLO smtp.nimag.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756077AbYLLDJ3 convert rfc822-to-8bit (ORCPT ); Thu, 11 Dec 2008 22:09:29 -0500 Received: from crookshanks.cine7.net (85-218-42-96.dclient.lsne.ch [85.218.42.96]) by smtp.nimag.net (Postfix) with ESMTP id 8141ACB0AA2; Fri, 12 Dec 2008 04:09:24 +0100 (CET) In-Reply-To: <200812120303.56997.jnareb@gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: 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. 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=3D3 (sorted by cat on each page): A:sort(name) split(max=3D3) 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=3D4) 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=3D3)' on each page. To be truly fair to the main sorting, we should not try to group categories and display the header for each consecutive group of entries from a distinct category: A-:sort(name) split(max=3D3) 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 Which in this case is painless as it only affects page 3, but it could lead to a mess of interleaved categories, and we kind of lose the purpose of category groups in the first place.. The point is that with A, you cannot determine whether you're on the right page to find project P (even if you know its category) by checking whether it's in the interval between the top and bottom entries. It's perhaps even more apparent if we sort by date: A:sort(year) split(max=3D3) 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=3D4) 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 :-) > P.S. It is IMHO better to use >=20 > for (my $i =3D $from; $i <=3D $to; $i++) { Ah sorry, I took the words from your earlier email too literally ("we can [...] use loop $from..$to there"). That's what happens when pseudocode is actually valid syntax in a language! Cheers, --=20 S=E9bastien Cevey / inso.cc