gitolite/doc/4-push-to-admin.mkd

# "push to admin" in gitolite

----

Gitosis's default mode of admin is by cloning and pushing the `gitosis-admin`
repo.  I call this "push to admin".  It's a very cool/cute feature, and I
loved it at first.

But it's a ***support nightmare***.  Half the gitosis angst on `#git` is
because of this feature.  Gitolite does not use or endorse this method for
people new to git, or ssh or (worse) both.

However, ***if*** you know git and ssh really, *really*, well and you know
what you're doing, this is a pretty nice thing to have -- does make life
easier, I admit.  So, here is how to make PTA (hey nice acronym, just missing
an "I") work on gitolite as well.

Note:

  * unlike the rest of gitolite, I can't help you with this unless you
    convince me very quickly it's not a layer 8 problem :-)

  * here's a test to see if you should use this feature: after reading this
    document, think about how you would switch back and forth between the
    normal method and push-to-admin.  If you can't immediately see what you
    would need to do, please don't use it :-)

The instructions are presented as shell commands; they should be fairly
obvious.  All paths are from the default `~/.gitolite.rc`; if you changed any,
make the same changes below.

----

>   **WARNING**: the "compilation" runs via a `post-update` hook.  Which, by
>   definition, runs *after* the push has successfully completed.  As a
>   result, a *compilation error* will be visible to the admin doing the `git
>   push` but will not otherwise look like an error to client-side git (in
>   terms of return codes, scripting, etc., or even the "git gui" if you
>   happen to use that for pushing).  So be sure to watch out for compile
>   error messages on push when you do this.

----

First, on the server, log on to the `git` userid, add a new repo called
`gitolite-admin` to the config file, give yourself `RW` or `RW+` rights to it,
and "compile":

    cd ~/.gitolite
    vim conf/gitolite.conf      # add gitolite-admin repo, etc
    src/gl-compile-conf

Now, if you look at the "compile" script, it has an *automatic* local commit
inside, just for safety, which kicks in every time you compile.  This only
works if it finds a ".git" directory, and it was designed as an "automatic
backup/safety net" type of thing, in case I accidentally deleted the whole
config file or something.

We need to disable this, because now we have a *better* repo, one that is
manually pushed, and presumably has proper commit messages!

    mv .git .disable.git        # yeah it's a hack, sue me

Now the compile command created an empty, bare, "gitolite-admin" repo, so we
seed it with the current contents of the config and keys.  (A note on the
`GIT_WORK_TREE` variable: I avoid setting these variables in the normal way
because I always forget to unset them later, and then when I `cd` to other
repos they play havoc with my git commands, so this is how I do it)

    cd ~/repositories/gitolite-admin.git
    GIT_WORK_TREE=/home/git/.gitolite git add conf/gitolite.conf keydir
    GIT_WORK_TREE=/home/git/.gitolite git commit -am start

Now we have to setup the post-update hook for push-to-admin to work.  The
hook should (1) make a forced checkout in the "live" config directory (which
is `~/.gitolite`), and (2) run the compile script.  So we create a hook with
the appropriate code in it, and then make it executable

    cat <<EOFPU > hooks/post-update
    #!/bin/sh

    GIT_WORK_TREE=/home/git/.gitolite git checkout -f

    cd /home/git/.gitolite
    src/gl-compile-conf
    EOFPU

    chmod +x hooks/post-update

----

Now get to your workstation, and

    git clone git@server:gitolite-admin.git

That's it, we're done.  You're in gitosis land as far as this is concerned
now.  So knock yourself out.  Or lock yourself out... :-)