bbaacfaee7
- 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
127 lines
5.3 KiB
Markdown
127 lines
5.3 KiB
Markdown
# 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 gito**lite**-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
|
|
|