Sophie

Sophie

distrib > Fedora > 14 > x86_64 > media > updates > by-pkgid > ba9fe7781d529b2e7b31d8489f5e0b8e > files > 12

gitolite-1.5.3-2.fc14.noarch.rpm

<h1>migrating from gitosis to gitolite</h1>

<p>[TODO: make the migration tool fix up gitweb and daemon control also...]</p>

<p>Migrating from gitosis to gitolite is pretty easy, because the basic design is
the same.</p>

<p>Here's how we migrated my work repos:</p>

<ol>
<li><p>login as the <code>git</code> user on the server, and get a bash shell prompt</p></li>
<li><p><strong>disable gitosis</strong> by renaming <code>/usr/bin/gitosis-serve</code> to something
else.  This will prevent users from pushing anything while you do the
backup, migration, etc.</p></li>
<li><p><strong>edit</strong> <code>~/.ssh/authorized_keys</code> and <strong>carefully</strong> 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).</p></li>
<li><p>For added safety, <strong>delete</strong> the post-update hook that gitosis-admin
installed</p>

<pre><code>rm ~/repositories/gitosis-admin.git/hooks/post-update
</code></pre>

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

<p>If you do not do this, an accidental push to the gitosis-admin repo will
mess up your <code>~/.ssh/authorized_keys</code> file</p></li>
<li><p>take a <strong>backup</strong> of the <code>~/repositories</code> directory</p></li>
</ol>

<p>Now, log off the server and get back to the client:</p>

<ol>
<li><p>follow instructions to install gitolite; see the <a href="http://github.com/sitaramc/gitolite/blob/pu/doc/0-INSTALL.mkd">install document</a>.
Make sure that you <strong>don't</strong> change the default path for <code>$REPO_BASE</code> if
you edit the config file!</p>

<p>This will give you a gitolite config that has the required entries for the
"gitolite-admin" repo.</p></li>
<li><p><strong>convert</strong> your gitosis config file and append it to your gitolite config
file.  Substitute the path for your gitosis-admin clone in <code>$GSAC</code> below,
and similarly the path for your gito*<em>lite</em>*-admin clone in <code>$GLAC</code></p>

<pre><code>src/gl-conf-convert &lt; $GSAC/gitosis.conf &gt;&gt; $GLAC/gitolite.conf
</code></pre>

<p>Be sure to check the file to make sure it converted correctly</p></li>
<li><p><strong>copy</strong> the keys from gitosis's keydir (same meanings for GSAC and GLAC)</p>

<pre><code>cp $GSAC/keydir/* $GLAC/keydir
</code></pre></li>
<li><p><strong>Important: expand any multi-key files you may have</strong>.  <a href="http://github.com/sitaramc/gitolite/blob/pu/doc/3-faq-tips-etc.mkd#multikeys">Here</a>'s an
explanation of what multi-keys are, how gitosis does them and how gitolite
does it differently.</p>

<p>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):</p>

<pre><code>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" &gt; ${b%.pub}@$i.pub
        (( i++ ))
    done
    mv $b $b.done
done
</code></pre>

<p>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.</p>

<p>At this point you can rename the split parts more appropriately, like
"sitaram@laptop.pub" and "sitaram@desktop.pub" or whatever.  <em>Please check
the files to make sure this worked properly</em></p></li>
<li><p>Check all your changes to your gitolite-admin clone, commit, and push</p></li>
</ol>