gitolite/doc/gsmigr.mkd
Sitaram Chamarty bbaacfaee7 (mostly) doc changes
- minor typo fixes, clarifications, etc.

  - keep sts.html url consistent, because many people link to
    http://sitaramc.github.com/gitolite/sts.html

  - create a common migration doc, so the old 'migr.html' does not 404
    when g3 docs become "main"

  - progit doc done

  - add gitosis convert script (FWIW)

  - a minor comment fix to Sugar.pm
2012-04-10 15:41:32 +05:30

5.3 KiB

migrating from gitosis to gitolite

[2012-04-09] Modified for gitolite g3. These instructions have not really been tested with g3, but are expected to work.

Migrating from gitosis to gitolite is fairly easy, because the basic design is the same.

There's only one thing that might trip up people: the userid. Gitosis uses gitosis. Gitolite can use any userid you want; most of the documentation uses git, while DEB/RPM packages use gitolite.

Here are the steps on the server:

  • (as 'gitosis' on the server) Rename ~/.ssh/authorized_keys to something else so that no one can accidentally push while you're doing this.

  • (as 'gitosis' on the server) For added safety, delete the post-update hook that gitosis-admin installed

    rm ~/repositories/gitosis-admin.git/hooks/post-update
    

    or at least rename it to .sample like all the other hooks hanging around, or edit it and comment out the line that calls gitosis-run-hook post-update.

  • (as 'gitosis' on the server) If you already use the update hook for some reason, you'll have to make that a [VREF][vref]. This is because gitolite uses the update hook for checking write access.

  • (as 'root' on the server) copy all of ~/repositories to the gitolite hosting user's home directory. Something like

    cp -a /home/gitosis/repositories /home/git
    chown -R git.git /home/git/repositories
    
  • (as 'root' and/or 'git' on the server) Follow instructions to install gitolite; see the [install document][install].

    This will give you a gitolite config that has the required entries for the "gitolite-admin" repo.

Now, log off the server and get back to the client. All subsequent instructions are to be read as "on gitolite admin's workstation".

  • clone the new gitolite-admin repo to your workstation. (You already have a clone of the gitosis-admin repo so now you have both).

  • convert your gitosis config file and append it to your gitolite config file. Substitute the path for your gitosis-admin clone in $GSAC below, and similarly the path for your gitolite-admin clone in $GLAC. (The convert-gitosis-conf program is a standalone program that you can bring over from any gitolite clone; you don't have to install all of gitolite on your workstation to use this):

    ./convert-gitosis-conf < $GSAC/gitosis.conf >> $GLAC/conf/gitolite.conf
    

    Be sure to check the file to make sure it converted correctly -- due it's "I only need it once" nature, this program has not received too much attention from anyone!

  • Remove the entry for the 'gitosis-admin' repo. You do not need it here and it may cause confusion.

  • copy the keys from gitosis's keydir (same meanings for GSAC and GLAC)

    cp $GSAC/keydir/* $GLAC/keydir
    

    If your gitosis-admin key was you@machine.pub, and you supplied the same one to gitolite's gl-setup program as you.pub when you installed gitolite, then you should remove you@machine.pub from the new keydir now. Otherwise you will have 2 pubkey files (you.pub and you@machine.pub) which are identical, which is not a good idea.

    Similarly, you should replace all occurrences of you@machine.pub with you in the conf/gitolite.conf file.

  • IMPORTANT: if you have any users with names like user@foo, where the part after the @ does not have a . in it (i.e., does not look like an email address), you need to change them, because gitolite uses that syntax for [enabling multi keys][multi-key].

    You have two choices in how to fix this. You can change the gitolite config so that all mention of user@foo is changed to just user.

    Or you can change each occurrence of user@foo to, say, user_foo and change the pubkey filename in keydir/ also the same way (user_foo.pub).

    Just to repeat, you do NOT need to do this if the username was like user@foo.bar, i.e., the part after the @ had a . in it, because then it looks like an email address.

  • IMPORTANT: expand any multi-key files you may have. Gitosis is happy to accept files containing more than one public key (one per line) and assign all the keys to the same user. Gitolite does not allow that; see [here][multi-key]'s for how gitolite handles multi-keys.

    So if you had any multi-keys in gitosis, they need to be carefully split into individual keys.

    You can split the keys manually, or use the following code (just copy-paste it into your xterm after "cd"-ing to your gitolite-admin repo clone):

    wc -l keydir/*.pub | grep -v total | grep -v -w 1 | while read a b
    do
        i=1
        cat $b|while read l
        do
            echo "$l" > ${b%.pub}@$i.pub
            (( i++ ))
        done
        mv $b $b.done
    done
    

    This will split each multi-key file (say "sitaram.pub") into individual files called "sitaram@1.pub", "sitaram@2.pub", etc., and rename the original to "sitaram.pub.done" so gitolite won't pick it up.

    At this point you can rename the split parts more appropriately, like "sitaram@laptop.pub" and "sitaram@desktop.pub" or whatever. Please check the files to make sure this worked properly

  • Check all your changes to your gitolite-admin clone, commit, and push