Bug 798051

There are two problems in the way config files are generated in each repository when $GL_BIG_CONFIG is enabled (both cases also apply to newer version in rawhide):

. the first one is related to the propagation of config hooks. Here is a quick way to reproduce the problem, on a fresh F16 :

yum install gitolite
su - gitolite
gl-setup /tmp/bellet.pub

Then I tweak the config file in the following way:

$GL_BIG_CONFIG = 1;
$GL_GITCONFIG_KEYS = "hooks\.mailinglist";

git clone gitolite.122.76:gitolite-admin

I edit conf/gitolite.conf:
-----------------------
@repogroup = testing

repo    gitolite-admin
        RW+     =   bellet

repo    @repogroup
        config hooks.mailinglist = root@localhost

repo    testing
        RW+     =   @all

testing "Testing owner" = "Testing software"
------------------------

git commit -a && git push

I modify the the hooks.mailinglist value in conf/gitolite.conf

git commit -a && git push

-> the hook modification is not propagated in
   /var/lib/gitolite/repositories/testing.git/config

I remove the testing description line from conf/gitolite.conf

git commit -a && git push

-> the hook modification is propagated

The suggested fix is to force can_read() to be called in setup_gitweb_access() with this patch :
--- sitaramc-gitolite-4c1e4b2/src/gitolite.pm.orig      2012-02-27 21:59:09.699580170 +0100
+++ sitaramc-gitolite-4c1e4b2/src/gitolite.pm   2012-02-27 21:59:28.802476445 +0100
@@ -482,7 +482,8 @@
         system("git config --remove-section gitweb 2>/dev/null");
     }

-    return ($desc or can_read($repo, 'gitweb'));
+    my $cr = can_read($repo, 'gitweb');
+    return ($desc or $cr);
         # this return value is used by the caller to write to projects.list
 }


The second problem is that config order is not respected when $GL_BIG_CONFIG=1. consider this case :

-------------------------
@repogroup = testing

repo    gitolite-admin
        RW+     =   bellet

repo    @repogroup
        config hooks.mailinglist = bellet2@localhost

repo    testing
        config hooks.mailinglist = bellet3@localhost

repo    testing
        RW+     =   @all
-------------------------

I would expect that the hook specific to the 'testing' repo would have priority on the same hook for the @repogroup containing the testing repo just above. this is not the case.

This other patch fixes that (partly adapted from upstream) :

@@ -650,7 +651,10 @@
         $repos{$dr}{DELETE_IS_D} = 1 if $repos{$r}{DELETE_IS_D};
         $repos{$dr}{CREATE_IS_C} = 1 if $repos{$r}{CREATE_IS_C};
         $repos{$dr}{NAME_LIMITS} = 1 if $repos{$r}{NAME_LIMITS};
-        $git_configs{$dr} = $git_configs{$r} if $git_configs{$r};
+        # this needs to copy the key-value pairs from RHS to LHS, not just
+        # assign RHS to LHS!  However, we want to roll in '@all' configs also
+        # into the actual $repo; there's no need to preserve the distinction
+        map { $git_configs{$repo}{$_} = $git_configs{$r}{$_} if not $git_configs{$repo}{$_} } keys %{$git_configs{$r}} if $git_configs{$r};

         for my $u ('@all', "$gl_user - wild", @user_plus, keys %perm_cats) {
             my $du = $gl_user; $du = '@all' if $u eq '@all' or ($perm_cats{$u} || '') eq '@all';

the idea is to collect the config key-values from the 'repo @repogroup' section when they don't overwrite existing config key-value for the same key in the 'repo testing' section. It doesn't resolve the ordering problem when the repo is part of several groups, but at least it gives a priority to the configuration of a single repo vs. the configuration of a group of repos.