gitolite/doc/migrate.mkd

127 lines
5.3 KiB
Markdown
Raw Normal View History

# F=migr migrating from gitosis to gitolite
2009-08-27 11:54:23 +02:00
HELP WANTED: these instructions have been revamped a bit recently
[2011-07-18], so if something doesn't work let me know.
[TODO: make the migration tool fix up gitweb and daemon control also...]
Migrating from gitosis to gitolite is fairly easy, because the basic design is
the same.
2009-08-27 11:54:23 +02:00
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`.
2009-08-28 02:56:23 +02:00
Here are the steps on the server:
2009-08-28 02:56:23 +02:00
* (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
2009-08-28 02:56:23 +02:00
rm ~/repositories/gitosis-admin.git/hooks/post-update
2009-08-28 02:56:23 +02:00
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, **rename** it (on each individual repository that has it) to
`update.secondary`. This is because gitolite uses the update hook for
checking write access.
2009-08-28 02:56:23 +02:00
* (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
2009-08-28 02:56:23 +02:00
* (as 'root' and/or 'git' on the server) Follow instructions to install
gitolite; see the [install document][install]. Make sure that you **don't**
change the default path for `$REPO_BASE` if you edit the config file!
2009-08-28 02:56:23 +02:00
This will give you a gitolite config that has the required entries for the
"gitolite-admin" repo.
2009-08-28 02:56:23 +02:00
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 gito**lite**-admin clone in `$GLAC`.
(The gl-conf-convert 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):
./gl-conf-convert < $GSAC/gitosis.conf >> $GLAC/conf/gitolite.conf
2009-08-28 02:56:23 +02:00
Be sure to check the file to make sure it converted correctly. Then
remove the entry for the 'gitosis-admin' repo. You do not need it here
and it may cause confusion.
2009-08-28 02:56:23 +02:00
* **copy** the keys from gitosis's keydir (same meanings for GSAC and GLAC)
2009-08-28 02:56:23 +02:00
cp $GSAC/keydir/* $GLAC/keydir
2009-08-28 02:56:23 +02:00
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][oldmultikeys].
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.
[This][multikey] will tell you more about these nuances. If you can
understand it.
* **IMPORTANT: expand any multi-key files you may have**. [Here][multikey]'s an
explanation of what multi-keys are, how gitosis does them and how gitolite
does it differently.
2009-08-28 02:56:23 +02:00
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):
2009-08-28 02:56:23 +02:00
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
2009-08-28 02:56:23 +02:00
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