6e29365316
I got tired of being told "TL;DR". Now the online versions of most documents fit on a page or two, or at least most of them do. The rest has been split out (and you can see the links to the split out sections right where the text is in the raw Markdown). This is much more pleasant to read, and I've improved the linking so it's much less effort for me to keep the links correct.
54 lines
2 KiB
Markdown
54 lines
2 KiB
Markdown
# F=packaging packaging gitolite
|
|
|
|
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.
|
|
|
|
**Step 1**: Clone the gitolite repo and run the make command inside the clone
|
|
|
|
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:
|
|
|
|
GL_PACKAGE_CONF="X"
|
|
|
|
* `conf/example.gitolite.rc` should have the following lines:
|
|
|
|
$GL_PACKAGE_CONF="X";
|
|
$GL_PACKAGE_HOOKS="Y";
|
|
|
|
**Step 3**: Move (or arrange to move) the files to their proper locations as
|
|
given below:
|
|
|
|
* everything in "src" goes somewhere on the PATH
|
|
* everything in "conf" goes to location "X"
|
|
* everything in "hooks" goes to location "Y"
|
|
|
|
**Step 4**: There is no step 4. Unless you count telling your users to run
|
|
`gl-setup` as a step :)
|
|
|
|
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".
|
|
|
|
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.
|