compile: make it easier to move repos into gitolite

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

doc/2-admin.mkd

@@ -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

src/gl-compile-conf

@@ -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" .