gitweb: Optional grouping of projects by category

This adds the GITWEB_GROUP_CATEGORIES option which, if enabled, will result in grouping projects by category on the project list page.

The category is specified for each project by the $GIT_DIR/category file or the 'category' variable in its configuration file.

The feature is inspired from Sham Chukoury's patch for the XMMS2 gitweb, but has been rewritten for the current gitweb development HEAD.

Thanks to Florian Ragwitz for Perl tips.

Signed-off-by Sebastien Cevey <[email protected]>

---

I submitted a previous version of this patch on July 27, but was told to wait for the end of the feature freeze. I submitted it again on September 5, but didn't get any reply. Hope to be luckier this time!

This is a new version of the patch, which has been rebased onto the current HEAD of the master branch.

 Makefile           |    2 +
 gitweb/README      |   11 +++
 gitweb/gitweb.css  |    5 ++
 gitweb/gitweb.perl |  173 +++++++++++++++++++++++++++++++++++-----------------
 4 files changed, 135 insertions(+), 56 deletions(-)

Makefile +1 -0

index 649cfb8..a8e8bbf 100644
@@ -211,6 +211,7 @@ GITWEB_EXPORT_OK =
 GITWEB_STRICT_EXPORT =
 GITWEB_BASE_URL =
 GITWEB_LIST =
+GITWEB_GROUP_CATEGORIES =
 GITWEB_HOMETEXT = indextext.html
 GITWEB_CSS = gitweb.css
 GITWEB_LOGO = git-logo.png

gitweb/README +5 -0

index 825162a..a6f82c5 100644
@@ -38,6 +38,11 @@ You can specify the following configuration variables when building GIT:
    using gitweb" in INSTALL file for gitweb to find out how to generate
    such file from scan of a directory. [No default, which means use root
    directory for projects]
+ * GITWEB_GROUP_CATEGORIES
+   Groups projects by category on the main projects list page if set
+   to true.  The category of a project is determined by the
+   $GIT_DIR/category file or the 'category' variable in its
+   configuration file.  [No default / Not set]
  * GITWEB_EXPORT_OK
    Show repository only if this file exists (in repository).  Only
    effective if this variable evaluates to true.  [No default / Not set]

@@ -188,6 +193,12 @@ not include variables usually directly set during build):
    full description is available as 'title' attribute (usually shown on
    mouseover).  By default set to 25, which might be too small if you

gitweb/gitweb.css +5 -0

index a01eac8..2dd45d6 100644
@@ -264,6 +264,11 @@ td.current_head {
 	text-decoration: underline;
 }
 
+td.category {
+	padding-top: 1em;
+	font-weight: bold;
+}
+
 table.diff_tree span.file_status.new {
 	color: #008000;
 }

gitweb/gitweb.perl +16 -8

index 933e137..c1bcd96 100755
@@ -87,6 +87,13 @@ our $projects_list = "++GITWEB_LIST++";
 # the width (in characters) of the projects list "Description" column
 our $projects_list_description_width = 25;
 
+# group projects by category on the projects list
+our $projects_list_group_categories = "++GITWEB_GROUP_CATEGORIES++";
+
+# default category if none specified
+# (leave the empty string for no category)
+our $project_list_default_category = "";
+
 # default order of projects list
 # valid values are none, project, descr, owner, and age
 our $default_projects_order = "project";

@@ -2001,18 +2008,28 @@ sub git_get_path_by_hash {
 ## ......................................................................
 ## git utility functions, directly accessing git repository
 
-sub git_get_project_description {
-	my $path = shift;
+sub git_get_project_config_from_file {
+	my ($name, $path) = @_;
 
 	$git_dir = "$projectroot/$path";
-	open my $fd, "$git_dir/description"
-		or return git_get_project_config('description');
-	my $descr = <$fd>;
+	open my $fd, "$git_dir/$name"
+		or return git_get_project_config($name);
+	my $conf = <$fd>;
 	close $fd;
-	if (defined $descr) {
-		chomp $descr;
+	if (defined $conf) {
+		chomp $conf;
 	}
-	return $descr;
+	return $conf;
+}

gitweb/gitweb.perl +3 -2

 sub git_get_project_ctags {

@@ -3907,8 +3924,9 @@ sub git_patchset_body {
 
 # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 
-# fills project list info (age, description, owner, forks) for each
-# project in the list, removing invalid projects from returned list
+# fills project list info (age, description, owner, category, forks)
+# for each project in the list, removing invalid projects from
+# returned list
 # NOTE: modifies $projlist, but does not remove entries from it
 sub fill_project_list_info {
 	my ($projlist, $check_forks) = @_;

@@ -3931,6 +3949,11 @@ sub fill_project_list_info {
 		if (!defined $pr->{'owner'}) {

gitweb/gitweb.perl +57 -45

+sub print_project_rows {
 	# actually uses global variable $project
-	my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
-
-	my ($check_forks) = gitweb_check_feature('forks');
-	my @projects = fill_project_list_info($projlist, $check_forks);
+	my ($projects, $from, $to, $check_forks, $show_ctags) = @_;
 
-	$order ||= $default_projects_order;
 	$from = 0 unless defined $from;
-	$to = $#projects if (!defined $to || $#projects < $to);
+	$to = $#$projects if (!defined $to || $#$projects < $to);
 
-	my %order_info = (
-		project => { key => 'path', type => 'str' },
-		descr => { key => 'descr_long', type => 'str' },
-		owner => { key => 'owner', type => 'str' },
-		age => { key => 'age', type => 'num' }
-	);
-	my $oi = $order_info{$order};
-	if ($oi->{'type'} eq 'str') {
-		@projects = sort {$a->{$oi->{'key'}} cmp $b->{$oi->{'key'}}} @projects;
-	} else {
-		@projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}} @projects;
-	}
-
-	my $show_ctags = gitweb_check_feature('ctags');
-	if ($show_ctags) {
-		my %ctags;
-		foreach my $p (@projects) {
-			foreach my $ct (keys %{$p->{'ctags'}}) {
-				$ctags{$ct} += $p->{'ctags'}->{$ct};
-			}
-		}
-		my $cloud = git_populate_project_tagcloud(\%ctags);
-		print git_show_project_tagcloud($cloud, 64);
-	}
-
-	print "<table class=\"project_list\">\n";
-	unless ($no_header) {
-		print "<tr>\n";
-		if ($check_forks) {
-			print "<th></th>\n";
-		}
-		print_sort_th('project', $order, 'Project');
-		print_sort_th('descr', $order, 'Description');
-		print_sort_th('owner', $order, 'Owner');
-		print_sort_th('age', $order, 'Last Change');
-		print "<th></th>\n" . # for links
-		      "</tr>\n";
-	}
 	my $alternate = 1;
 	my $tagfilter = $cgi->param('by_tag');
 	for (my $i = $from; $i <= $to; $i++) {
-		my $pr = $projects[$i];
+		my $pr = $projects->[$i];
 
 		next if $tagfilter and $show_ctags and not grep { lc $_ eq lc $tagfilter } keys %{$pr->{'ctags'}};
 		next if $searchtext and not $pr->{'path'} =~ /$searchtext/

@@ -4060,6 +4054,73 @@ sub git_project_list_body {
 		      "</td>\n" .
 		      "</tr>\n";
 	}
+}
+
+sub git_project_list_body {
+	my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
+
+	my ($check_forks) = gitweb_check_feature('forks');
+	my @projects = fill_project_list_info($projlist, $check_forks);
+
+	$order ||= $default_projects_order;
+
+	my %order_info = (
+		project => { key => 'path', type => 'str' },
+		descr => { key => 'descr_long', type => 'str' },
+		owner => { key => 'owner', type => 'str' },
+		age => { key => 'age', type => 'num' }
+	);
+	my $oi = $order_info{$order};
+	if ($oi->{'type'} eq 'str') {
+		@projects = sort {$a->{$oi->{'key'}} cmp $b->{$oi->{'key'}}} @projects;
+	} else {
+		@projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}} @projects;
+	}
+
+	my $show_ctags = gitweb_check_feature('ctags');
+	if ($show_ctags) {
+		my %ctags;
+		foreach my $p (@projects) {
+			foreach my $ct (keys %{$p->{'ctags'}}) {
+				$ctags{$ct} += $p->{'ctags'}->{$ct};
+			}
+		}
+		my $cloud = git_populate_project_tagcloud(\%ctags);
+		print git_show_project_tagcloud($cloud, 64);
+	}
+
+	print "<table class=\"project_list\">\n";
+	unless ($no_header) {
+		print "<tr>\n";
+		if ($check_forks) {
+			print "<th></th>\n";
+		}
+		print_sort_th('project', $order, 'Project');
+		print_sort_th('descr', $order, 'Description');
+		print_sort_th('owner', $order, 'Owner');
+		print_sort_th('age', $order, 'Last Change');
+		print "<th></th>\n" . # for links
+		      "</tr>\n";
+	}
+
+	if ($projects_list_group_categories) {
+		my %categories = build_category_list(\@projects);
+		foreach my $cat (sort keys %categories) {
+			unless ($cat eq "") {

gitweb/gitweb.perl +4 -0

+	} else {
+		print_project_rows(\@projects, $from, $to, $check_forks, $show_ctags);
+	}
+
 	if (defined $extra) {
 		print "<tr>\n";
 		if ($check_forks) {

Signature · 1 line

1.5.6.5

On Tue, 2 Dec 2008, Sebastien Cevey wrote:
...

Quoted 3 lines

I submitted a previous version of this patch on July 27, but was told to wait for the end of the feature freeze. I submitted it again on September 5, but didn't get any reply. Hope to be luckier this time!

Unfortunately it looks like you hit the edge of feature freeze again.

Quoted 2 lines

This adds the GITWEB_GROUP_CATEGORIES option which, if enabled, will result in grouping projects by category on the project list page.

Should this really be build time configuration (to set default value)?

Unfortunately it looks like you hit the edge of feature freeze again.

By the way, there was alternate patch series by Gustavo Sverzut Barbieri on 29 July 2008 adding categories support to gitweb:
http://thread.gmane.org/gmane.comp.version-control.git/90553
with live demo at http://staff.get-e.org/

Here is and important issue when adding categories support: how division into categories interplays with sorting of projects.

Another issue is how categories interplay with limiting number of projects displayed. Currently it is no issue, because projects list page is not divided into pages, but I think you didn't address this in your patch.

This adds the $projects_list_group_categories option which, if enabled, will result in grouping projects by category on the project list page. The category is specified for each project by the $GIT_DIR/category file or the 'category' variable in its configuration file. By default, projects are put in the $project_list_default_category category.

Note:
- Categories are always sorted alphabetically, with projects in each category sorted according to the globally selected $order.

- When displaying a subset of all the projects, only the categories with projects in the chosen subset are displayed.

Quoted 6 lines · Sébastien Cevey

This adds the $projects_list_group_categories option which, if enabled, will result in grouping projects by category on the project list page. The category is specified for each project by the $GIT_DIR/category file or the 'category' variable in its configuration file. By default, projects are put in the $project_list_default_category category.

Quoted 3 lines

Note:
- Categories are always sorted alphabetically, with projects in each category sorted according to the globally selected $order.

I am not sure if always sorting the categories alphabetically is a severe enough restriction, but if it was, you can use @project_list_categories array that disables the feature when empty and otherwise enumerates the categories in order. Just an idle thought.

Quoted 2 lines

- When displaying a subset of all the projects, only the categories with projects in the chosen subset are displayed.

Could you clarify this bit?

It is not very clear to me how this subset selection happens. As far as I can see, the user does not choose the category to view, but lets the usual page limiting to decide at which project to start and stop placing on the page, and only show the ones in the same category as the one that happened to be the first on the page.

While I think both the introduction of "git_get_project_config_or_file"

which is a generalized interface usable between description and the new feature and the refactoring of project_list_body into a seprate function "print_project_rows" is a good idea, the patch would have been much easier to read if these preparatory refactoring steps (without any new feature) were done as a separate patch followed by the main patch to introduce the new feature.

Extract the printing of project rows on the project page into a separate print_project_rows function. This makes it easier to reuse the code to print different subsets of the whole project list.

The row printing code is merely moved into a separate function, but note that $projects is passed as a reference now.

Signed-off-by Sebastien Cevey <[email protected]>

---

Boo, the diff is still quite scarier than it really should be...

 gitweb/gitweb.perl |  103 +++++++++++++++++++++++++++++-----------------------
 1 files changed, 57 insertions(+), 46 deletions(-)

gitweb/gitweb.perl +0 -0

index b31274c..a6bb702 100755
@@ -3972,59 +3972,19 @@ sub print_sort_th {
 	}
 }
 

gitweb/gitweb.perl +53 -41

-	$order ||= $default_projects_order;
 	$from = 0 unless defined $from;
-	$to = $#projects if (!defined $to || $#projects < $to);
-
-	my %order_info = (
-		project => { key => 'path', type => 'str' },
-		descr => { key => 'descr_long', type => 'str' },
-		owner => { key => 'owner', type => 'str' },
-		age => { key => 'age', type => 'num' }
-	);
-	my $oi = $order_info{$order};
-	if ($oi->{'type'} eq 'str') {
-		@projects = sort {$a->{$oi->{'key'}} cmp $b->{$oi->{'key'}}} @projects;
-	} else {
-		@projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}} @projects;
-	}
+	$to = $#$projects if (!defined $to || $#$projects < $to);
 
-	my $show_ctags = gitweb_check_feature('ctags');
-	if ($show_ctags) {
-		my %ctags;
-		foreach my $p (@projects) {
-			foreach my $ct (keys %{$p->{'ctags'}}) {
-				$ctags{$ct} += $p->{'ctags'}->{$ct};
-			}
-		}
-		my $cloud = git_populate_project_tagcloud(\%ctags);
-		print git_show_project_tagcloud($cloud, 64);
-	}
-
-	print "<table class=\"project_list\">\n";
-	unless ($no_header) {
-		print "<tr>\n";
-		if ($check_forks) {
-			print "<th></th>\n";
-		}
-		print_sort_th('project', $order, 'Project');
-		print_sort_th('descr', $order, 'Description');
-		print_sort_th('owner', $order, 'Owner');
-		print_sort_th('age', $order, 'Last Change');
-		print "<th></th>\n" . # for links
-		      "</tr>\n";
-	}
 	my $alternate = 1;
 	my $tagfilter = $cgi->param('by_tag');
 	for (my $i = $from; $i <= $to; $i++) {
-		my $pr = $projects[$i];
+		my $pr = $projects->[$i];
 
 		next if $tagfilter and $show_ctags and not grep { lc $_ eq lc $tagfilter } keys %{$pr->{'ctags'}};
 		next if $searchtext and not $pr->{'path'} =~ /$searchtext/

@@ -4068,6 +4028,57 @@ sub git_project_list_body {
 		      "</td>\n" .
 		      "</tr>\n";
 	}
+}
+
+sub git_project_list_body {
+	my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
+
+	my ($check_forks) = gitweb_check_feature('forks');
+	my @projects = fill_project_list_info($projlist, $check_forks);
+
+	$order ||= $default_projects_order;
+
+	my %order_info = (
+		project => { key => 'path', type => 'str' },
+		descr => { key => 'descr_long', type => 'str' },
+		owner => { key => 'owner', type => 'str' },
+		age => { key => 'age', type => 'num' }
+	);
+	my $oi = $order_info{$order};
+	if ($oi->{'type'} eq 'str') {
+		@projects = sort {$a->{$oi->{'key'}} cmp $b->{$oi->{'key'}}} @projects;
+	} else {
+		@projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}} @projects;
+	}
+
+	my $show_ctags = gitweb_check_feature('ctags');
+	if ($show_ctags) {
+		my %ctags;
+		foreach my $p (@projects) {
+			foreach my $ct (keys %{$p->{'ctags'}}) {
+				$ctags{$ct} += $p->{'ctags'}->{$ct};
+			}
+		}
+		my $cloud = git_populate_project_tagcloud(\%ctags);
+		print git_show_project_tagcloud($cloud, 64);
+	}
+
+	print "<table class=\"project_list\">\n";
+	unless ($no_header) {
+		print "<tr>\n";
+		if ($check_forks) {
+			print "<th></th>\n";
+		}
+		print_sort_th('project', $order, 'Project');
+		print_sort_th('descr', $order, 'Description');
+		print_sort_th('owner', $order, 'Owner');
+		print_sort_th('age', $order, 'Last Change');
+		print "<th></th>\n" . # for links
+		      "</tr>\n";
+	}
+
+	print_project_rows(\@projects, $from, $to, $check_forks, $show_ctags);
+
 	if (defined $extra) {
 		print "<tr>\n";
 		if ($check_forks) {

Signature · 1 line

1.5.6.5

This adds the $projects_list_group_categories option which, if enabled, will result in grouping projects by category on the project list page. The category is specified for each project by the $GIT_DIR/category file or the 'category' variable in its configuration file. By default, projects are put in the $project_list_default_category category.

Note:
- Categories are always sorted alphabetically, with projects in each category sorted according to the globally selected $order.
- When displaying a subset of all the projects (page limiting), the category headers are only displayed for projects present on the page.

The feature is inspired from Sham Chukoury's patch for the XMMS2 gitweb, but has been rewritten for the current gitweb development HEAD. The CSS for categories is inspired from Gustavo Sverzut Barbieri's patch to group projects by path.

Thanks to Florian Ragwitz for Perl tips.

Signed-off-by Sebastien Cevey <[email protected]>

---

Cleaner patch this time indeed. Still no fancy sorting of categories, only alphabetical.

 gitweb/README      |   16 ++++++++++++
 gitweb/gitweb.css  |    7 +++++
 gitweb/gitweb.perl |   67 +++++++++++++++++++++++++++++++++++++++++++++++++--
 3 files changed, 87 insertions(+), 3 deletions(-)

gitweb/README +2 -0

index 825162a..f8f8872 100644
@@ -188,6 +188,15 @@ not include variables usually directly set during build):
    full description is available as 'title' attribute (usually shown on
    mouseover).  By default set to 25, which might be too small if you
    use long project descriptions.
+ * $projects_list_group_categories
+   Enables the grouping of projects by category on the project list page.

gitweb/README +0 -0

@@ -269,6 +278,13 @@ You can use the following files in repository:
    from the template during repository creation. You can use the
    gitweb.description repo configuration variable, but the file takes
    precedence.

gitweb/gitweb.css +7 -0

index a01eac8..64f2a41 100644
@@ -264,6 +264,13 @@ td.current_head {
 	text-decoration: underline;
 }
 
+td.category {
+	background-color: #d9d8d1;
+	border-top: 1px solid #000000;
+	border-left: 1px solid #000000;
+	font-weight: bold;
+}
+
 table.diff_tree span.file_status.new {
 	color: #008000;
 }

gitweb/gitweb.perl +1 -0

index a6bb702..97a9b73 100755
@@ -87,6 +87,14 @@ our $projects_list = "++GITWEB_LIST++";
 # the width (in characters) of the projects list "Description" column
 our $projects_list_description_width = 25;
 
+# group projects by category on the projects list

gitweb/gitweb.perl +3 -2

 sub git_get_project_ctags {
 	my $path = shift;
 	my $ctags = {};

@@ -3915,8 +3928,9 @@ sub git_patchset_body {
 
 # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 
-# fills project list info (age, description, owner, forks) for each
-# project in the list, removing invalid projects from returned list
+# fills project list info (age, description, owner, category, forks)
+# for each project in the list, removing invalid projects from
+# returned list
 # NOTE: modifies $projlist, but does not remove entries from it
 sub fill_project_list_info {
 	my ($projlist, $check_forks) = @_;

@@ -3939,6 +3953,11 @@ sub fill_project_list_info {
 		if (!defined $pr->{'owner'}) {

gitweb/gitweb.perl +2 -0

@@ -3956,6 +3975,19 @@ sub fill_project_list_info {
 	return @projects;
 }
 
+# returns a hash of categories, containing the list of project
+# belonging to each category

gitweb/gitweb.perl +13 -0

+		foreach my $cat (sort keys %categories) {
+			my $num_cats = @{$categories{$cat}};
+
+			# out of the window to display, done
+			last if defined $to and $to < 0;
+
+			# in the window to display
+			if (!defined $from or $from < $num_cats) {
+				unless ($cat eq "") {
+					print "<tr>\n";
+					if ($check_forks) {
+						print "<td></td>\n";
+					}

gitweb/gitweb.perl +0 -0

 	if (defined $extra) {
 		print "<tr>\n";

Signature · 1 line

1.5.6.5

Nice... but perhaps it would be better to simply pass $from / $to to build_projlist_by_category function, and have in %categories only projects which are shown...

well, unless filtered out in print_project_rows() by $show_ctags; so I think that there is nonzero probability of empty (no project shown) categories.

I don't think that the games we play with $from / $to would be enough. Check what happens (I think that it wouldn't work correctly) if we have something like that:

project | category | shown
--------------------------

  1      | A        |
  2      | A        |
  3      | B        | Y
  4      | C        | Y
  5      | B        | Y
  6      | C        |
  7      | C        |

I'll try to examine the code in more detail later... currently I don't know why but I can't git-am the second patch (this patch) correctly...

Quoted 3 lines · Jakub Narebski

Nice... but perhaps it would be better to simply pass $from / $to to build_projlist_by_category function, and have in %categories only projects which are shown...

Ah you're right, we could do that, I hadn't thought of it. Sounds cleaner than the $from/$to dance I did in this patch.

Quoted 3 lines

well, unless filtered out in print_project_rows() by $show_ctags; so I think that there is nonzero probability of empty (no project shown) categories.

Mh indeed, in fact this could happen any time we reach one of the 'next' statements in the loop in print_project_rows(), when performing search, tag filtering, etc...

Actually, assuming the project list is split into page, this can also lead to empty pages (if no project on the page matches the filter). To avoid empty categories, it's a bit tricky since the header is printed before we determine whether there are matching projects..

I need to read the code more carefully, but it seems that one solution would be to add a function that determines whether a project should be displayed or not (according to tags and search and forks); then we can map this function on the list of projects.

I could do it if it sounds sane to you.

Quoted 2 lines

I'll try to examine the code in more detail later... currently I don't know why but I can't git-am the second patch (this patch) correctly...

This is the third patch, are you sure you applied 1 and 2 before?

Thanks for your careful and supportive comments!

Quoted 6 lines

Quoted 3 lines

Nice... but perhaps it would be better to simply pass $from / $to to build_projlist_by_category function, and have in %categories only projects which are shown...

Ah you're right, we could do that, I hadn't thought of it. Sounds cleaner than the $from/$to dance I did in this patch.

[...] we can simply pass $from and $to to build_projlist_by_category(), and use loop $from..$to there.

Somehow I couldn't apply second patch in series:

 $ git am -3 -u "[PATCH v3 2_3] gitweb: Split git_project_list_body in two functions.txt"
 Applying: gitweb: Split git_project_list_body in two functions
 error: patch failed: gitweb/gitweb.perl:3972
 error: gitweb/gitweb.perl: patch does not apply
 fatal: sha1 information is lacking or useless (gitweb/gitweb.perl).
 Repository lacks necessary blobs to fall back on 3-way merge.
 Cannot fall back to three-way merge.
 Patch failed at 0001.

Quoted 4 lines · Jakub Narebski

Quoted 4 lines

Quoted 3 lines

Nice... but perhaps it would be better to simply pass $from / $to to build_projlist_by_category function, and have in %categories only projects which are shown...

Quoted 5 lines

Quoted 2 lines

Ah you're right, we could do that, I hadn't thought of it. Sounds cleaner than the $from/$to dance I did in this patch.

[...] we can simply pass $from and $to to build_projlist_by_category(), and use loop $from..$to there.

I just tried, it works but we first need to sort @projects by category.

I'm gonna re-send the three patches as a new version.

I just tried, it works but we first need to sort @projects by category.

I don't understand.
[...]
I propose to change it to:

Quoted 6 lines · Jakub Narebski

I just tried, it works but we first need to sort @projects by category.

I don't understand.
[...]
I propose to change it to:

Well in my previous iteration of the patch (v3), the printing of projects with categories is done using:

  foreach my $cat (sort keys %categories) {

So everything was already sorted by category (and then by whichever property you picked inside each category). You seemed okay with it, but requested that I documented that behaviour in the commit log.

To maintain the same result with your proposed change (which is what I submitted in my patch), we need to sort by categories first (AFAIK Perl sort retains the original order inside equivalence classes of comparison key?), otherwise splice(projlist, from, to) doesn't return the expected subset.

And no, we don't need to sort by categories first. Let me explain in more detail a bit.

P.S. It is IMHO better to use

for (my $i = $from; $i <= $to; $i++) {

Quoted 2 lines · Jakub Narebski

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=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 :-)

Introduce a git_get_file_or_project_config utility function to retrieve a repository variable either from a plain text file in the $GIT_DIR

or else from 'gitweb.$variable' in the repository config (e.g. 'description').

Signed-off-by Sebastien Cevey <[email protected]>

---
 gitweb/gitweb.perl |   24 ++++++++++++++++--------
 1 files changed, 16 insertions(+), 8 deletions(-)

gitweb/gitweb.perl +0 -0

index 933e137..b31274c 100755

gitweb/gitweb.perl +4 -5

 	$git_dir = "$projectroot/$path";
-	open my $fd, "$git_dir/description"
-		or return git_get_project_config('description');
-	my $descr = <$fd>;
+	open my $fd, "$git_dir/$name"
+		or return git_get_project_config($name);
+	my $conf = <$fd>;
 	close $fd;
-	if (defined $descr) {
-		chomp $descr;
+	if (defined $conf) {

gitweb/gitweb.perl +0 -0

 sub git_get_project_ctags {

Signature · 1 line

1.5.6.5

I am not sure if always sorting the categories alphabetically is a severe enough restriction, but if it was, you can use @project_list_categories array that disables the feature when empty and otherwise enumerates the categories in order. Just an idle thought.

Quoted 2 lines

- When displaying a subset of all the projects, only the categories with projects in the chosen subset are displayed.

Could you clarify this bit?

It is not very clear to me how this subset selection happens. As far as I can see, the user does not choose the category to view, but lets the usual page limiting to decide at which project to start and stop placing on the page

and only show the ones in the same category as the one that happened to be the first on the page.

[1] OT: I didn't find a simple command to do this:

    $ git diff ..the-end-state > finish.patch
    $ patch -p1 < finish.patch
    $ git commit -a -s

(where the original HEAD and the-end-state have an older MRCA with
rewritten history inbetween, and I don't want to apply that history and solve conflicts, just "get my tree to the end state".)

Any tip?