Migrating from gitosis to gitolite

So we finally migrated successfully from gitosis to gitolite. I’ll try to explain how to do it easily.

Client side, part 1:

  1. Update your local gitosis-admin repository

Server side, part 1:

  1. Disable write access to your gitroot by either changing the “git” users homedir (I prefer this method) or by renaming the ~/.ssh/authorized_keys file. This is important to ensure gitolite gets a clean authorized_keys file
  2. Make a backup of your gitroot by using rsync, tar or whatever else..
  3. Cleanup/Remove your old gitroot
  4. Install gitolite
  5. Copy the example gitolite.rc into the git users homedir (e.g. ~/.gitolite.rc) and set your settings (Don’t forget to chown/chmod it later)
  6. Run “gl-setup /path/to/your/pubkey” as “git” user

Client side, part 2:

  1. git clone git+ssh://git.yourdomain.tld/gitolite-admin.git
  2. Grab my convert.pl script
  3. cd /path/to/gitosis-admin
  4. perl ~/convert.pl [/path/to/your/gitosis.conf] >> /path/to/gitolite.conf
  5. Commit & Push your changes but DON’T add your old keys from keydir yet!

All repositories will be created after your push, ignore the pubkey warnings for now.

Server side, part 2 (Run commands as user “git”):

  1. Create a tmp directory and cd into it
  2. git clone -q –bare /path/to/your/gitroot/backup/repository.git
  3. cd repository.git
  4. GL_BYPASS_UPDATE_HOOK=1 git push -q –mirror /path/to/the/new/gitroot/repository.git

With clone and push –mirror we ensure that we don’t keep any old hooks or other stuff from gitosis.

In most cases it might be enough to simply remove the old hooks e.g. by running “find /path/to/gitroot/ -type d -name hooks -exec rm -f {}/* \;”, then you could skip the server part 2 and use your old gitroot instead.

I did part 2 to ensure we really have a clean new gitroot. So decide yourself.

If you need to push via ssh, create a migration user in gitolite.conf

repo @all
    RW+ = migration

and add the public key as well.

Then start a ssh-agent and ssh-add your public key. Now you don’t need to enter the passphrase for each push.

If you have a lot of repositories then just write a small shell script including the git clone/push stuff.

Once you’re done: Remove the migration user and its key.

Now add all your old gitosis keys to gitolite. That’s it!

If you need the post-update hook from git (update-git-server-info) then just link it into your ~/.gitolite/hooks/common dir.

ln -s /usr/share/git-core/templates/hooks/post-update.sample ~/.gitolite/hooks/common/post-update

Run gl-setup again (as user “git”) and you’re done.

Each time when you modify your .gitolite.rc, add/change hooks or update gitolite itself then simply run gl-setup. NOTE: Old hooks will not be removed by gitolite/gl-setup!

Gentoo user can choose between the upstream/vanilla version dev-vcs/gitolite or our own fork dev-vcs/gitolite-gentoo.

3 thoughts on “Migrating from gitosis to gitolite”

  1. Hi,

    I have tried to use your guide, but I ran into various troubles. First of all it is important as which user you run the above commands, e.g. on the server you have the choice of the admin user which can ssh into the machine and the git user. It was not obvious to me that gl-setup should be run as the git-user. Then it seems to be important to deactivate gitosis at some point. E.g. .ssh/authorized_keys still contained all the gitosis keys making gitolite fail. (This is somehow implicit in ‘clean-up your git root’)

    Then the script, which worked fine by the way, is hard to download because of the formatting of the blog. In the end I fetched it using RSS , but copy and paste fails horribly.

    Currently I’m stuck with step 4 of the second server side. Did you test this, I’m convinced that this will fail because you run into what is described under “bypassing gitolite without intending to” on https://github.com/sitaramc/gitolite/blob/pu/doc/ssh-troubleshooting.mkd
    I don’t know what is a safe way to bare-push to these repos. Probably I will deaktivate the failing update-hook there and activate it after doing all the migration.

    In any case, thanks for this guide, O hope I can overcome my glitches.

    1. Update: The update hook of the newly created empty repositories checks for the environment variable ‘GL_BYPASS_UPDATE_HOOK’, so when doing the migration locally one has to replace 4. with

      GL_BYPASS_UPDATE_HOOK=1 git push -q –mirror /path/to/the/new/gitroot/repository.git

      1. Hey Thomas,

        > It was not obvious to me that gl-setup should be run as the git-user.

        Has been fixed.

        > Then it seems to be important to deactivate gitosis at some point. E.g. .ssh/authorized_keys still contained all the gitosis keys making gitolite fail. (This is somehow implicit in ‘clean-up your git root’)

        Yeah, I mentioned it in “Server side part 1.1″ but I extended the sentence a bit now.

        > Then the script, which worked fine by the way, is hard to download because of the formatting of the blog. In the end I fetched it using RSS , but copy and paste fails horribly.

        Sorry, I had/have some issues with b2evolution and file extensions :D

        I also added the “GL_BYPASS_UPDATE_HOOK=1″ variable, thanks!

Comments are closed.