deac/gitolite
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

compile: make it easier to move repos into gitolite

Browse source 
when repos are copied over from elsewhere, one had to run easy install
once again to make the new (OS-copied) repo contain the proper update
hook.

We eliminate this step now, using a new, empty, "hook" as a sentinel and
having "compile" check/fix all repos' hooks.

Since you have to add the repos to conf anyway, this makes it as
seamless as possible.  The correct sequence now is

  - (server) copy the repo at the OS level
  - (admin clone) add it to conf/gitolite.conf, commit, push
This commit is contained in:
Sitaram Chamarty 2010-03-07 19:05:56 +05:30
parent be92feca6d
commit de0ecd0431
3 changed files with 32 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
doc/2-admin.mkd
View file

@ -7,6 +7,7 @@ In this document:
* administer
* adding users and repos
* moving pre-existing repos into gitolite
* specifying gitweb and daemon access
* custom hooks
* custom git config
@ -40,6 +41,25 @@ Please read on to see how to do this correctly.
* when done, commit your changes and push
#### moving pre-existing repos into gitolite
One simple way to add a pre-existing repo to gitolite is to let gitolite
create it as a brand new repo as in the previous section, and then, from an
existing clone, "push --all" to the new one.
However, if you have many existing repos to add, this can be time-consuming
and error-prone. Here's how to take a bunch of existing repos and add them to
gitolite:
* make sure they're *bare* repos ;-)
* log on to the server and copy the repos to `$REPO_BASE` (which defaults to
`~/repositories`), making sure that the directory names end in ".git".
* back on your workstation, add each repo (without the `.git` suffix) to
`conf/gitolite.conf` in your gitolite-admin repo clone. Then add, commit,
push.
#### specifying gitweb and daemon access
This is a feature that I personally do not use (corporate environments don't

0
hooks/common/gitolite-hooked Normal file
View file

13
src/gl-compile-conf
View file

@ -61,7 +61,7 @@ $Data::Dumper::Sortkeys = sub { return [ reverse sort keys %{$_[0]} ]; };
open STDOUT, ">", "/dev/null" if (@ARGV and shift eq '-q');
# these are set by the "rc" file
our ($GL_ADMINDIR, $GL_CONF, $GL_KEYDIR, $GL_CONF_COMPILED, $REPO_BASE, $REPO_UMASK, $PROJECTS_LIST, $GIT_PATH, $SHELL_USERS, $GL_WILDREPOS, $GL_GITCONFIG_KEYS);
our ($GL_ADMINDIR, $GL_CONF, $GL_KEYDIR, $GL_CONF_COMPILED, $REPO_BASE, $REPO_UMASK, $PROJECTS_LIST, $GIT_PATH, $SHELL_USERS, $GL_WILDREPOS, $GL_GITCONFIG_KEYS, $GL_PACKAGE_HOOKS);
# and these are set by gitolite.pm
our ($REPONAME_PATT, $REPOPATT_PATT, $USERNAME_PATT, $AUTH_COMMAND, $AUTH_OPTIONS, $ABRT, $WARN);
@ -400,6 +400,17 @@ for my $repo (sort keys %repos) {
# new_repo would have chdir'd us away; come back
wrap_chdir("$repo_base_abs");
}
# when repos are copied over from elsewhere, one had to run easy install
# once again to make the new (OS-copied) repo contain the proper update
# hook. Perhaps we can make this easier now, and eliminate the easy
# install, with a quick check (and a new, empty, "hook" as a sentinel)
unless (-l "$repo.git/hooks/gitolite-hooked") {
ln_sf("$GL_ADMINDIR/hooks/common", "*", "$repo.git/hooks");
# in case of package install, GL_ADMINDIR is no longer the top cop;
# override with the package hooks
ln_sf("$GL_PACKAGE_HOOKS/common", "*", "$repo.git/hooks") if $GL_PACKAGE_HOOKS;
}
}
warn "\n\t\t***** WARNING *****\n" .