d78bbe8c3e
- added comments to easy install to help do it manually
- README: some stuff moved to tips doc, brief summary of extras
(over gitosis) added
- INSTALL: major revamp, easy install and manual install,
much shorter and much more readable!
plus other docs changed as needed, and updated the tips doc to roll in
some details from "update.mkd" in the "ml" branch
83 lines
3.1 KiB
Markdown
83 lines
3.1 KiB
Markdown
# migrating from gitosis to gitolite
|
|
|
|
[TODO: make the migration tool fix up gitweb and daemon control also...]
|
|
|
|
Migrating from gitosis to gitolite is pretty easy, because the basic design is
|
|
the same.
|
|
|
|
Here's how we migrated my work repos:
|
|
|
|
1. login as the `git` user on the server, and get a bash shell prompt
|
|
|
|
2. **disable gitosis** by renaming `/usr/bin/gitosis-serve` to something
|
|
else. This will prevent users from pushing anything while you do the
|
|
backup, migration, etc.
|
|
|
|
3. **edit** `~/.ssh/authorized_keys` and **carefully** remove all the lines
|
|
containing "gitosis-serve", as well as the marker line that says
|
|
"auto-generated by gitosis, DO NOT REMOVE", then save the file. If the
|
|
file did not have any other keys and is now empty, don't worry -- save it
|
|
anyway because gitolite expects the file to be present (even if it is
|
|
empty).
|
|
|
|
4. 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`.
|
|
|
|
If you do not do this, an accidental push to the gitosis-admin repo will
|
|
mess up your `~/.ssh/authorized_keys` file
|
|
|
|
5. take a **backup** of the `~/repositories` directory
|
|
|
|
Now, log off the server and get back to the client:
|
|
|
|
1. follow instructions to install gitolite; see install document. Make sure
|
|
that you **don't** change the default path for `$REPO_BASE`!
|
|
|
|
2. **convert** your gitosis 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`
|
|
|
|
src/conf-convert.pl < $GSAC/gitosis.conf > $GLAC/gitolite.conf
|
|
|
|
Be sure to check the file to make sure it converted correctly
|
|
|
|
3. **copy** the keys from gitosis's keydir (same meanings for GSAC and GLAC)
|
|
|
|
cp $GSAC/keydir/* $GLAC/keydir
|
|
|
|
4. **Important: expand any multi-key files you may have**. See the "faq,
|
|
tips, etc" document in the doc directory for an explanation of what
|
|
multi-keys are, how gitosis does them and how gitolite does it
|
|
differently.
|
|
|
|
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*
|
|
|
|
5. Check all your changes to your gitolite-admin clone, commit, and push
|