2012-03-19 11:45:21 +01:00
|
|
|
#!/usr/bin/perl
|
|
|
|
|
|
|
|
# update git-config entries in each repo
|
|
|
|
# ----------------------------------------------------------------------
|
|
|
|
|
|
|
|
use FindBin;
|
|
|
|
|
2012-04-06 16:59:05 +02:00
|
|
|
use lib $ENV{GL_LIBDIR};
|
2012-03-19 11:45:21 +01:00
|
|
|
use Gitolite::Rc;
|
|
|
|
use Gitolite::Common;
|
|
|
|
use Gitolite::Conf::Load;
|
|
|
|
|
|
|
|
use strict;
|
|
|
|
use warnings;
|
|
|
|
|
|
|
|
my $RB = $rc{GL_REPO_BASE};
|
2012-03-30 02:41:06 +02:00
|
|
|
_chdir($RB);
|
POST_CREATE efficiency... (please read below if you care)
The POST_CREATE trigger is called when
* a user creates a new "wild" repo,
* a user uses the "perms" command, and
* a user uses the "fork" command.
The trigger calls 3 programs (see rc file):
post-compile/update-git-configs
post-compile/update-gitweb-access-list
post-compile/update-git-daemon-access-list
(They are also called by the POST_COMPILE trigger, by the way.)
However, the 3 programs shown are a bit wasteful -- they run through
*all* the repos when really only *one* repo has been affected.
This patch
* passes the repo name to the 3 programs (duh!)
* adds the optimisation to the first of the 3 programs listed above
(the one dealing with 'git config').
For the other two programs (gitweb and git-daemon), you have 3 choices:
* if you don't have too many repos, ignore the problem.
* take out the 2nd and 3rd lines from the POST_CREATE list in the rc
file, so they don't run.
Then run 'gitolite trigger POST_COMPILE' from cron at regular
intervals. (Note that is POST_COMPILE not POST_CREATE!) However,
this means that gitweb and daemon permissions won't be current
immediately after someone adds a new repo or sets perms etc.; they
get updated only on the next cron run.
* patch the programs to add this optimisation (and send me the
patches). The optimisation would check if arg-1 ($1 in shell,
$ARGV[0] in perl) is 'POST_CREATE', and if it is, take the *next*
argument as a repo name that may have changed.
2012-04-22 17:55:54 +02:00
|
|
|
|
2012-05-25 08:58:14 +02:00
|
|
|
# ----------------------------------------------------------------------
|
|
|
|
# skip if arg-0 is POST_CREATE and no arg-2 (user name) exists; this means
|
|
|
|
# it's been triggered by a *normal* (not "wild") repo creation, which in turn
|
|
|
|
# means a POST_COMPILE should be following so there's no need to waste time
|
|
|
|
# running this once for each new repo
|
|
|
|
exit 0 if @ARGV and $ARGV[0] eq 'POST_CREATE' and not $ARGV[2];
|
|
|
|
|
POST_CREATE efficiency... (please read below if you care)
The POST_CREATE trigger is called when
* a user creates a new "wild" repo,
* a user uses the "perms" command, and
* a user uses the "fork" command.
The trigger calls 3 programs (see rc file):
post-compile/update-git-configs
post-compile/update-gitweb-access-list
post-compile/update-git-daemon-access-list
(They are also called by the POST_COMPILE trigger, by the way.)
However, the 3 programs shown are a bit wasteful -- they run through
*all* the repos when really only *one* repo has been affected.
This patch
* passes the repo name to the 3 programs (duh!)
* adds the optimisation to the first of the 3 programs listed above
(the one dealing with 'git config').
For the other two programs (gitweb and git-daemon), you have 3 choices:
* if you don't have too many repos, ignore the problem.
* take out the 2nd and 3rd lines from the POST_CREATE list in the rc
file, so they don't run.
Then run 'gitolite trigger POST_COMPILE' from cron at regular
intervals. (Note that is POST_COMPILE not POST_CREATE!) However,
this means that gitweb and daemon permissions won't be current
immediately after someone adds a new repo or sets perms etc.; they
get updated only on the next cron run.
* patch the programs to add this optimisation (and send me the
patches). The optimisation would check if arg-1 ($1 in shell,
$ARGV[0] in perl) is 'POST_CREATE', and if it is, take the *next*
argument as a repo name that may have changed.
2012-04-22 17:55:54 +02:00
|
|
|
# ----------------------------------------------------------------------
|
|
|
|
# if called from POST_CREATE, we have only a single repo to worry about
|
|
|
|
if (@ARGV and $ARGV[0] eq 'POST_CREATE') {
|
|
|
|
my $repo = $ARGV[1];
|
|
|
|
fixup_config($repo);
|
|
|
|
|
|
|
|
exit 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
# ----------------------------------------------------------------------
|
|
|
|
# else it's all repos (i.e., called from POST_COMPILE)
|
|
|
|
|
2012-03-19 11:45:21 +01:00
|
|
|
my $lpr = list_phy_repos();
|
|
|
|
|
|
|
|
for my $pr (@$lpr) {
|
POST_CREATE efficiency... (please read below if you care)
The POST_CREATE trigger is called when
* a user creates a new "wild" repo,
* a user uses the "perms" command, and
* a user uses the "fork" command.
The trigger calls 3 programs (see rc file):
post-compile/update-git-configs
post-compile/update-gitweb-access-list
post-compile/update-git-daemon-access-list
(They are also called by the POST_COMPILE trigger, by the way.)
However, the 3 programs shown are a bit wasteful -- they run through
*all* the repos when really only *one* repo has been affected.
This patch
* passes the repo name to the 3 programs (duh!)
* adds the optimisation to the first of the 3 programs listed above
(the one dealing with 'git config').
For the other two programs (gitweb and git-daemon), you have 3 choices:
* if you don't have too many repos, ignore the problem.
* take out the 2nd and 3rd lines from the POST_CREATE list in the rc
file, so they don't run.
Then run 'gitolite trigger POST_COMPILE' from cron at regular
intervals. (Note that is POST_COMPILE not POST_CREATE!) However,
this means that gitweb and daemon permissions won't be current
immediately after someone adds a new repo or sets perms etc.; they
get updated only on the next cron run.
* patch the programs to add this optimisation (and send me the
patches). The optimisation would check if arg-1 ($1 in shell,
$ARGV[0] in perl) is 'POST_CREATE', and if it is, take the *next*
argument as a repo name that may have changed.
2012-04-22 17:55:54 +02:00
|
|
|
fixup_config($pr);
|
|
|
|
}
|
|
|
|
|
|
|
|
sub fixup_config {
|
|
|
|
my $pr = shift;
|
2012-06-21 23:52:22 +02:00
|
|
|
my $creator = creator($pr);
|
POST_CREATE efficiency... (please read below if you care)
The POST_CREATE trigger is called when
* a user creates a new "wild" repo,
* a user uses the "perms" command, and
* a user uses the "fork" command.
The trigger calls 3 programs (see rc file):
post-compile/update-git-configs
post-compile/update-gitweb-access-list
post-compile/update-git-daemon-access-list
(They are also called by the POST_COMPILE trigger, by the way.)
However, the 3 programs shown are a bit wasteful -- they run through
*all* the repos when really only *one* repo has been affected.
This patch
* passes the repo name to the 3 programs (duh!)
* adds the optimisation to the first of the 3 programs listed above
(the one dealing with 'git config').
For the other two programs (gitweb and git-daemon), you have 3 choices:
* if you don't have too many repos, ignore the problem.
* take out the 2nd and 3rd lines from the POST_CREATE list in the rc
file, so they don't run.
Then run 'gitolite trigger POST_COMPILE' from cron at regular
intervals. (Note that is POST_COMPILE not POST_CREATE!) However,
this means that gitweb and daemon permissions won't be current
immediately after someone adds a new repo or sets perms etc.; they
get updated only on the next cron run.
* patch the programs to add this optimisation (and send me the
patches). The optimisation would check if arg-1 ($1 in shell,
$ARGV[0] in perl) is 'POST_CREATE', and if it is, take the *next*
argument as a repo name that may have changed.
2012-04-22 17:55:54 +02:00
|
|
|
|
2012-05-04 13:03:04 +02:00
|
|
|
my $gc = git_config( $pr, '.', 1 );
|
2012-03-30 02:41:06 +02:00
|
|
|
while ( my ( $key, $value ) = each( %{$gc} ) ) {
|
2012-03-19 11:45:21 +01:00
|
|
|
next if $key =~ /^gitolite-options\./;
|
2012-03-30 02:41:06 +02:00
|
|
|
if ( $value ne "" ) {
|
|
|
|
system( "git", "config", "--file", "$RB/$pr.git/config", $key, $value );
|
2012-03-19 11:45:21 +01:00
|
|
|
} else {
|
2012-03-30 02:41:06 +02:00
|
|
|
system( "git", "config", "--file", "$RB/$pr.git/config", "--unset-all", $key );
|
2012-03-19 11:45:21 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|