2009-08-27 11:54:23 +02:00
|
|
|
# installing gitolite
|
|
|
|
|
2009-11-18 10:07:04 +01:00
|
|
|
[Update 2009-11-18: easy install now works from msysgit also!]
|
|
|
|
|
2010-02-10 11:49:20 +01:00
|
|
|
Gitolite is somewhat unusual as far as "server" software goes -- every userid
|
2010-04-26 18:25:02 +02:00
|
|
|
on the server is a potential "gitolite host".
|
2010-02-10 11:49:20 +01:00
|
|
|
|
2009-10-11 05:01:59 +02:00
|
|
|
This document tells you how to install gitolite. After the install is done,
|
2009-10-30 16:55:06 +01:00
|
|
|
you may want to see the [admin document][admin] for adding users, repos, etc.
|
2009-10-11 05:01:59 +02:00
|
|
|
|
2010-02-27 08:16:02 +01:00
|
|
|
**Please note** that gitolite depends heavily on proper ssh setup and pubkey
|
|
|
|
based access. Sadly, most people don't know ssh as well as they think they
|
|
|
|
do. To make matters worse, ssh problems in gitolite don't always look like
|
|
|
|
ssh problems. Please read about [ssh troubleshooting][doc6] if you have *any*
|
|
|
|
kind of trouble installing gitolite!
|
|
|
|
|
2009-10-30 16:55:06 +01:00
|
|
|
[admin]: http://github.com/sitaramc/gitolite/blob/pu/doc/2-admin.mkd
|
2010-02-27 08:16:02 +01:00
|
|
|
[doc6]: http://github.com/sitaramc/gitolite/blob/pu/doc/6-ssh-troubleshooting.mkd
|
2009-10-30 16:55:06 +01:00
|
|
|
|
2009-10-11 05:01:59 +02:00
|
|
|
In this document:
|
|
|
|
|
2010-02-10 11:49:20 +01:00
|
|
|
* install methods
|
|
|
|
* user install
|
2009-10-25 14:53:15 +01:00
|
|
|
* typical example run
|
|
|
|
* advantages over the older install methods
|
|
|
|
* disadvantages
|
2010-02-10 11:49:20 +01:00
|
|
|
* upgrades
|
|
|
|
* other notes
|
|
|
|
* system install / user setup
|
2010-04-11 00:39:50 +02:00
|
|
|
* multiple gitolite instances
|
2009-10-11 05:01:59 +02:00
|
|
|
* next steps
|
2010-02-10 11:49:20 +01:00
|
|
|
* appendix A: server and client requirements for user install
|
|
|
|
* server
|
|
|
|
* install workstation
|
|
|
|
* admin workstation(s)
|
2010-02-16 02:09:27 +01:00
|
|
|
* appendix B: uninstalling gitolite
|
2010-02-25 15:56:33 +01:00
|
|
|
* appendix C: NOTE TO PACKAGE MAINTAINERS
|
2010-02-10 11:49:20 +01:00
|
|
|
|
|
|
|
----
|
|
|
|
|
|
|
|
### install methods
|
|
|
|
|
|
|
|
There are 2 ways to install gitolite: The **user-install** mode was the
|
|
|
|
traditional way, and is used when *any* of the following is true:
|
|
|
|
|
|
|
|
* you don't have root on your "server" (some types of hosting setups, many
|
|
|
|
corporate paranoia setups ;-)
|
|
|
|
* your server distro does not have gitolite in its package repositories
|
|
|
|
* your server distro's package repositories have an old version of gitolite
|
|
|
|
* you want to stay current with the latest gitolite versions
|
|
|
|
* your server is not Linux (maybe AIX, or Solaris, etc.)
|
|
|
|
|
|
|
|
The "user install" section describes this method.
|
|
|
|
|
|
|
|
The **system-install followed by user-setup** mode is used when you (or
|
|
|
|
someone who has root) has installed an RPM or DEB of gitolite and you intend
|
|
|
|
to use that version.
|
|
|
|
|
|
|
|
The "system install / user setup" section describes this method.
|
2009-10-11 05:01:59 +02:00
|
|
|
|
|
|
|
----
|
|
|
|
|
2010-02-10 11:49:20 +01:00
|
|
|
### user install
|
2009-10-10 09:08:22 +02:00
|
|
|
|
2010-04-26 18:25:02 +02:00
|
|
|
The `gl-easy-install` script makes installing very easy for this case. **This
|
|
|
|
script will setup everything on the server, but you have to run it on your
|
|
|
|
workstation, NOT on the server!**
|
2009-10-10 09:08:22 +02:00
|
|
|
|
2009-10-30 16:55:06 +01:00
|
|
|
Assumptions/pre-requisites:
|
2009-10-10 09:08:22 +02:00
|
|
|
|
|
|
|
* you have a server to host gitolite
|
|
|
|
* git is installed on that server (and so is perl)
|
|
|
|
* you have a userid on that server
|
2009-10-30 16:55:06 +01:00
|
|
|
* you have ssh-pubkey (**password-less**) login to that userid
|
2009-12-10 12:37:46 +01:00
|
|
|
* if you have only password access, run `ssh-keygen -t rsa` to create a
|
|
|
|
new keypair if needed, then run `ssh-copy-id user@host`. If you do
|
|
|
|
not have `ssh-copy-id`, read doc/3-faq-tips-etc.mkd and look for
|
|
|
|
`ssh-copy-id` in that file for instructions
|
2009-10-10 09:08:22 +02:00
|
|
|
* you have a clone or an archive of gitolite somewhere on your workstation
|
2009-12-10 12:37:46 +01:00
|
|
|
* if you don't have one, just run `git clone git://github.com/sitaramc/gitolite`
|
2010-02-10 11:49:20 +01:00
|
|
|
* your workstation has bash (even msysgit bash will do)
|
2009-10-10 09:08:22 +02:00
|
|
|
|
2009-12-10 12:37:46 +01:00
|
|
|
Once you have all this, just `cd` to that clone and run `src/gl-easy-install`
|
|
|
|
and follow the prompts! (Running it without any arguments shows you usage
|
|
|
|
plus other useful info).
|
2009-10-10 09:08:22 +02:00
|
|
|
|
2009-10-25 14:53:15 +01:00
|
|
|
#### typical example run
|
|
|
|
|
|
|
|
A typical run for me is:
|
|
|
|
|
2009-11-13 00:33:09 +01:00
|
|
|
src/gl-easy-install -q git my.git.server sitaram
|
2009-10-25 14:53:15 +01:00
|
|
|
|
|
|
|
`-q` stands for "quiet" mode -- very minimal output, no verbose descriptions
|
|
|
|
of what it is going to do, and no pauses unless absolutely needed. However,
|
|
|
|
if you're doing this for the first time or you appreciate knowing what it is
|
|
|
|
actually doing, I suggest you skip the `-q`.
|
|
|
|
|
2010-04-26 18:25:02 +02:00
|
|
|
A detailed transcript of an install done using this method can be found in
|
|
|
|
[doc/7-install-transcript.mkd][7it].
|
|
|
|
|
|
|
|
[7it]: http://github.com/sitaramc/gitolite/blob/pu/doc/7-install-transcript.mkd
|
|
|
|
|
2009-10-10 09:08:22 +02:00
|
|
|
#### advantages over the older install methods
|
|
|
|
|
|
|
|
* all ssh problems reduced to **just one pre-requisite**: enable ssh pubkey
|
|
|
|
(password-less) access to the server from your workstation first
|
|
|
|
* the script takes care of all the server side work
|
|
|
|
* when done:
|
|
|
|
* you get two different pubkeys (the original one for command line
|
|
|
|
access as before, plus a new one, created by the script, for gitolite
|
|
|
|
access)
|
|
|
|
* you can admin gitolite by commit+push a "gitolite-admin" repo, just
|
|
|
|
like gitosis (i.e., full "push to admin" power!)
|
|
|
|
|
|
|
|
#### disadvantages
|
|
|
|
|
2009-10-30 16:55:06 +01:00
|
|
|
* need a recent bash
|
2009-10-10 09:08:22 +02:00
|
|
|
|
2010-02-10 11:49:20 +01:00
|
|
|
#### upgrades
|
2009-11-06 04:29:32 +01:00
|
|
|
|
|
|
|
Upgrading gitolite is easy.
|
|
|
|
|
|
|
|
To upgrade, pull the latest "master" (or other) branch in your gitolite repo
|
|
|
|
clone, then run the same exact command you ran to do the install, except you
|
|
|
|
can leave out the last argument.
|
|
|
|
|
|
|
|
And you might want to add a `-q` to speed things up :-)
|
|
|
|
|
|
|
|
Note that this only upgrades the software. Unlike earlier versions, it does
|
|
|
|
**not** touch the `conf/gitolite.conf` file or the contents of `keydir` in any
|
|
|
|
way. I decided that it is not possible to **safely** let an upgrade do
|
|
|
|
something meaningful with them -- fiddling with existing config files (as
|
|
|
|
opposed to merely creating one which did not exist) is best left to a human.
|
|
|
|
|
2010-02-10 11:49:20 +01:00
|
|
|
#### other notes
|
2009-08-30 08:38:54 +02:00
|
|
|
|
2009-11-13 00:33:09 +01:00
|
|
|
* if you run `src/gl-easy-install` without the `-q` option, you will be
|
2009-10-30 16:55:06 +01:00
|
|
|
given a chance to edit `~/.gitolite.rc`. You can change any options (such
|
|
|
|
as paths, for instance), but be sure to keep the perl syntax -- you
|
|
|
|
*don't* have to know perl to do so, it's fairly easy to guess in this
|
|
|
|
limited case.
|
2009-08-27 11:54:23 +02:00
|
|
|
|
2010-04-26 18:25:02 +02:00
|
|
|
----
|
|
|
|
|
2010-02-10 11:49:20 +01:00
|
|
|
### system install / user setup
|
|
|
|
|
2010-04-26 18:25:02 +02:00
|
|
|
(Note: other than getting a public key from the admin's workstation,
|
|
|
|
everything in this mode of install happens on the server).
|
|
|
|
|
|
|
|
In this mode, the software is first installed system-wide, then the user runs
|
|
|
|
a command to set up the hosting, supplying a public key.
|
|
|
|
|
|
|
|
The root user can **install the software system-wide**, using either a package
|
|
|
|
(rpm, deb, etc.), or by using the `gl-system-install` script. (Run the script
|
|
|
|
without any arguments for a brief usage message. If that's not clear enough,
|
|
|
|
read Appendix C below for details.)
|
|
|
|
|
|
|
|
A normal user can then **set up the hosting** by running a command like this:
|
2010-02-10 11:49:20 +01:00
|
|
|
|
2010-04-26 18:25:02 +02:00
|
|
|
gl-setup adminname.pub
|
2010-02-10 11:49:20 +01:00
|
|
|
|
2010-04-26 18:25:02 +02:00
|
|
|
where adminname.pub is a copy of a public key from that user's workstation.
|
2010-02-10 11:49:20 +01:00
|
|
|
|
2010-04-26 18:25:02 +02:00
|
|
|
The first time this is run, it will create a "gitolite-admin" repo and
|
|
|
|
populate it with the right configuration for whoever has the corresponding
|
|
|
|
private key to clone and push it. In other words, that person is the
|
|
|
|
administrator for this particular gitolite instance.
|
2010-02-10 11:49:20 +01:00
|
|
|
|
|
|
|
If your system administrator upgrades gitolite itself, things will usually
|
|
|
|
just work without any change; you should not have to do anything special.
|
|
|
|
However, some new features may require additional settings in your
|
|
|
|
`~/.gitolite.rc` file.
|
|
|
|
|
|
|
|
Finally, in the rare case that you managed to lose your keys to the admin repo
|
|
|
|
and want to supply a new pubkey, you can use this command to replace any such
|
|
|
|
key. Could be useful in an emergency -- just get your new "yourname.pub" to
|
|
|
|
the server and run the same command as above.
|
|
|
|
|
|
|
|
**IMPORTANT**: there are two variables in the `~/.gitolite.rc` file:
|
|
|
|
`$GL_PACKAGE_CONF` and `$GL_PACKAGE_HOOKS`. If you remove or change either of
|
|
|
|
them, expect trouble :-)
|
|
|
|
|
2010-04-11 00:39:50 +02:00
|
|
|
#### multiple gitolite instances
|
|
|
|
|
2010-04-26 18:25:02 +02:00
|
|
|
With this mode of install, it's trivial to create multiple gitolite instances
|
2010-04-11 00:39:50 +02:00
|
|
|
(say one for each department, on some mega company-wide server). You can even
|
|
|
|
do this without giving shell access to the admins. Here's an example with
|
|
|
|
just two "departments", and their admins Alice and Bob:
|
|
|
|
|
|
|
|
* create userids `webbrowser_repos` and `webserver_repos`
|
|
|
|
* ask Alice and Bob for their pubkeys; copy them to the respective home
|
|
|
|
directories for convenience
|
|
|
|
* run `su - webbrowser_repos`, then `gl-setup alice.pub`
|
|
|
|
* (similarly with `webserver_repos` and `bob.pub`, and so on for others)
|
|
|
|
|
|
|
|
That's it. The URL for all web browser projects is now something like
|
|
|
|
`webbrowser_repos@server:reponame`, and similarly for the others.
|
|
|
|
|
|
|
|
Notice that you only have to do this once for each "department", and it's
|
|
|
|
really just one command after creating the userid. None of these admins need
|
|
|
|
to have a command line on the server, so don't give them the passwords if you
|
|
|
|
don't need to -- the pubkey will allow them to be gitolite admins on their
|
|
|
|
domain, and that's quite enough for normal operations.
|
|
|
|
|
2009-10-11 05:01:59 +02:00
|
|
|
### next steps
|
2009-08-27 11:54:23 +02:00
|
|
|
|
2009-10-30 16:55:06 +01:00
|
|
|
The last message produced by the easy install script should tell you how to
|
|
|
|
add users, repos, etc., and you will find more details in the [admin][admin]
|
|
|
|
document.
|
2009-11-18 09:07:14 +01:00
|
|
|
|
|
|
|
<a name="server_reqs"></a>
|
|
|
|
|
2010-02-10 11:49:20 +01:00
|
|
|
### appendix A: server and client requirements for user install
|
2009-11-18 09:07:14 +01:00
|
|
|
|
|
|
|
There are 3 machines *potentially* involved in installing and administering
|
|
|
|
gitolite.
|
|
|
|
|
|
|
|
#### server
|
|
|
|
|
|
|
|
This is where gitolite is eventually installed. You need a *normal* userid
|
|
|
|
(typically "git" but can be anything) on this machine; root access is *not*
|
2009-11-22 05:51:22 +01:00
|
|
|
needed, but it has to be some sort of Unix (not Windows).
|
2009-11-18 09:07:14 +01:00
|
|
|
|
|
|
|
You need the following software on it:
|
|
|
|
|
|
|
|
* git
|
|
|
|
* can be in a non-PATH location if you are unable to install it
|
|
|
|
normally; see the `$GIT_PATH` variable in the "rc" file
|
|
|
|
* perl
|
|
|
|
* default install is fine; no special modules are needed
|
|
|
|
* (a normal install of git also requires/installs perl, so you probably
|
|
|
|
have it already)
|
|
|
|
* openssh server
|
|
|
|
* (I guess any ssh server that can understand the `authorized_keys` file
|
|
|
|
format should work)
|
|
|
|
|
|
|
|
#### install workstation
|
|
|
|
|
|
|
|
Installing or upgrading the gitolite software itself is best done by running
|
2009-11-18 10:07:04 +01:00
|
|
|
the easy-install program from a gitolite clone.
|
2009-11-18 09:07:14 +01:00
|
|
|
|
2009-11-18 10:07:04 +01:00
|
|
|
This script is heavily dependent on bash, so you need a machine with a bash
|
|
|
|
shell. Even the bash that comes with msysgit is fine, if you don't have a
|
|
|
|
Linux box handy.
|
2009-11-18 09:07:14 +01:00
|
|
|
|
2009-11-18 10:07:04 +01:00
|
|
|
If you have neither Linux nor Windows+msysgit, you still have a few
|
|
|
|
alternatives:
|
2009-11-18 09:07:14 +01:00
|
|
|
|
2009-11-18 10:07:04 +01:00
|
|
|
* use a different userid on the same server (assuming it has bash)
|
|
|
|
* use the same userid on the same server (same assumption)
|
|
|
|
* manually simulate the script directly on the server (doable, but tedious)
|
2009-11-18 09:07:14 +01:00
|
|
|
|
|
|
|
#### admin workstation(s)
|
|
|
|
|
|
|
|
When you install gitolite, it creates a repository called "gitolite-admin" and
|
|
|
|
gives you permissions on it.
|
|
|
|
|
|
|
|
Administering gitolite (adding repos/users, assigning permissions, etc) is
|
|
|
|
done by cloning this repo, making changes to a file called
|
|
|
|
`conf/gitolite.conf`, adding users' pubkeys to `keydir/`, and pushing the
|
|
|
|
changes back to the server.
|
|
|
|
|
2009-11-18 10:07:04 +01:00
|
|
|
Which means all this can be done from *any* machine. You'll normally do it
|
|
|
|
from the same machine you used to install gitolite, but it doesn't have to be
|
|
|
|
the same one, as long as your pubkey has been added and permissions given to
|
|
|
|
allow you to push to the gitolite-admin repo.
|
2010-02-16 02:09:27 +01:00
|
|
|
|
|
|
|
<a name="uninstall"></a>
|
|
|
|
|
2010-02-25 15:56:33 +01:00
|
|
|
### appendix B: uninstalling gitolite
|
2010-02-16 02:09:27 +01:00
|
|
|
|
|
|
|
Sometimes you might find gitolite is overkill -- you have only one user
|
|
|
|
(yourself) pushing maybe. Or maybe gitolite is just not enough -- you want a
|
|
|
|
web-based front end that users can use to manage their keys themselves, etc.,
|
|
|
|
in which case you'd probably switch to [github][g1], [girocco][g2],
|
2010-04-16 03:01:04 +02:00
|
|
|
[indefero][g3] or [gitorious][g4]. [Gerrit][g5] is quite nice too, if you
|
|
|
|
want collaborative code review there's nothing like it. Either way, you'd
|
|
|
|
like to uninstall gitolite.
|
2010-02-16 02:09:27 +01:00
|
|
|
|
|
|
|
[g1]: http://github.com
|
|
|
|
[g2]: http://repo.or.cz/w/girocco.git
|
|
|
|
[g3]: http://www.indefero.net/
|
|
|
|
[g4]: http://gitorious.com/
|
2010-04-16 03:01:04 +02:00
|
|
|
[g5]: http://code.google.com/p/gerrit/
|
|
|
|
|
|
|
|
Uninstalling gitolite is fairly easy, although it is manual. (We'll assume
|
|
|
|
`$REPO_BASE` in the rc file was left at its default of `~/repositories`; if
|
|
|
|
not, adjust accordingly):
|
2010-02-16 02:09:27 +01:00
|
|
|
|
2010-04-16 03:01:04 +02:00
|
|
|
**server side tasks**
|
2010-02-16 02:09:27 +01:00
|
|
|
|
|
|
|
* edit `~/.ssh/authorized_keys` and delete the `# gitolite start` and `#
|
|
|
|
gitolite end` markers and all the lines between them. This will prevent
|
|
|
|
any of your users from attempting a push while you are doing this.
|
|
|
|
|
|
|
|
If you are the only user, and/or *need* one or more of those keys to
|
|
|
|
continue to access this account (like if one of them is your laptop or
|
|
|
|
your home desktop etc.) then instead of deleting the line you can just
|
|
|
|
delete everything upto but not including the words "ssh-rsa" or "ssh-dss".
|
|
|
|
|
|
|
|
* Now remove (or move aside or rename to something else if you're paranoid)
|
|
|
|
the following files and directories.
|
|
|
|
|
|
|
|
~/.gitolite
|
|
|
|
~/.gitolite.rc
|
|
|
|
~/repositories/gitolite-admin.git
|
|
|
|
|
2010-04-16 03:01:04 +02:00
|
|
|
* You can remove all of `~/repositories` if you have not really started
|
|
|
|
using gitolite properly yet; that's your choice.
|
|
|
|
|
|
|
|
If you *do* need to preserve the other repos and continue to use them,
|
|
|
|
remove all the `update` hooks that git installs on each repository. The
|
|
|
|
easiest way is:
|
2010-02-16 02:09:27 +01:00
|
|
|
|
|
|
|
find ~/repositories -wholename "*.git/hooks/update" | xargs rm -f
|
|
|
|
|
|
|
|
but you can do it manually if you want to be careful.
|
|
|
|
|
2010-04-16 03:01:04 +02:00
|
|
|
**client side tasks**
|
|
|
|
|
|
|
|
* Any remote users that still have access must update their clone's remote
|
|
|
|
URLs (edit `.git/config` in the repo) to prefix `repositories/` before the
|
|
|
|
actual path used, in order for the remote to still work. This is because
|
|
|
|
you'll now be accessing it through plain ssh, which means you have to give
|
|
|
|
it the full path.
|
|
|
|
|
|
|
|
* Finally, you as the gitolite admin will probably have a host stanza for
|
|
|
|
"gitolite" in your *client*'s `~/.ssh/config`. Find and delete lines that
|
|
|
|
look like this:
|
|
|
|
|
|
|
|
host gitolite
|
|
|
|
user git
|
|
|
|
hostname your.server
|
|
|
|
port 22
|
|
|
|
identityfile ~/.ssh/your-gitolite-admin-username
|
2010-02-25 15:56:33 +01:00
|
|
|
|
|
|
|
### appendix C: NOTE TO PACKAGE MAINTAINERS
|
2010-02-10 11:49:20 +01:00
|
|
|
|
|
|
|
Here's how you'd package gitolite. In the following description, location "X"
|
|
|
|
can be, say, `/usr/share/gitolite/conf` or some such, and similarly location
|
|
|
|
"Y" can be perhaps `/usr/share/gitolite/hooks`. It's upto your distro
|
|
|
|
policies where they are.
|
|
|
|
|
2010-03-12 05:54:53 +01:00
|
|
|
**Step 1**: Clone the gitolite repo and run the make command inside the clone
|
2010-02-10 11:49:20 +01:00
|
|
|
|
2010-03-12 05:54:53 +01:00
|
|
|
git clone git://github.com/sitaramc/gitolite.git
|
|
|
|
cd gitolite
|
|
|
|
make pu.tar # or "make master.tar" or "make v1.2.tar" etc
|
|
|
|
|
|
|
|
Then you explode the tar file in some temporary location.
|
|
|
|
|
|
|
|
*Alternatively, you can `git checkout` the tag or branch you want, and run
|
|
|
|
this command in the clone directly*:
|
|
|
|
|
|
|
|
git describe --tags --long > conf/VERSION
|
|
|
|
|
|
|
|
**Step 2**: Now make the following changes (no trailing slashes in the
|
|
|
|
location values please):
|
|
|
|
|
|
|
|
* `src/gl-setup` should have the following line:
|
2010-02-10 11:49:20 +01:00
|
|
|
|
|
|
|
GL_PACKAGE_CONF="X"
|
|
|
|
|
2010-03-12 05:54:53 +01:00
|
|
|
* `conf/example.gitolite.rc` should have the following lines:
|
2010-02-10 11:49:20 +01:00
|
|
|
|
|
|
|
$GL_PACKAGE_CONF="X";
|
|
|
|
$GL_PACKAGE_HOOKS="Y";
|
|
|
|
|
2010-03-12 05:54:53 +01:00
|
|
|
* delete `src/gl-easy-install`; that script is meant for a totally different
|
|
|
|
mode of installation and does *not* play well in this mode :-)
|
|
|
|
|
|
|
|
**Step 3**: Move (or arrange to move) the files to their proper locations as
|
|
|
|
given below:
|
2010-02-10 11:49:20 +01:00
|
|
|
|
|
|
|
* everything in "src" goes somewhere on the PATH
|
|
|
|
* everything in "conf" goes to location "X"
|
|
|
|
* everything in "hooks" goes to location "Y"
|
|
|
|
|
2010-03-12 05:54:53 +01:00
|
|
|
**Step 4**: There is no step 4. Unless you count telling your users to run
|
|
|
|
`gl-setup` as a step :)
|
2010-02-10 11:49:20 +01:00
|
|
|
|
2010-03-12 05:54:53 +01:00
|
|
|
On the initial install (urpmi, yum install, or apt-get install), you could
|
|
|
|
also choose to setup a userid called "gitolite", and run "gl-setup" as that
|
|
|
|
user; however I do not know how you would come up with the initial pubkey that
|
|
|
|
is needed. Anyway, the point is that the "gitolite" user is no more special
|
|
|
|
than any other in terms of hosting gitolite. Any user can host gitolite on
|
|
|
|
his userid by just running "gl-setup".
|
2010-02-10 11:49:20 +01:00
|
|
|
|
|
|
|
When you upgrade, just overwrite all the files; it'll all just work. In fact,
|
|
|
|
other than the initial "gl-setup" run, the only time a gitolite hosting user
|
|
|
|
has to actually do anything is to edit their own `~/.gitolite.rc` file if they
|
|
|
|
want to enable or disable specific features.
|