mirror of
https://github.com/wahyd4/gitolite.git
synced 2026-08-17 00:45:52 +10:00
170 lines
7.2 KiB
HTML
170 lines
7.2 KiB
HTML
<head>
|
|
<title>
|
|
what users (not admins) need to know about gitolite
|
|
</title>
|
|
<style>
|
|
body { background: #fff; margin-left: 40px; font-size: 0.9em; font-family: sans-serif; max-width: 800px; }
|
|
h1 { background: #ffb; margin-left: -30px; border-top: 5px solid #ccc; }
|
|
h2 { background: #ffb; margin-left: -20px; border-top: 3px solid #ddd; }
|
|
h3 { background: #ffb; margin-left: -10px; }
|
|
h4 { background: #ffb; }
|
|
code { font-size: 1.1em; background: #ddf; }
|
|
pre { margin-left: 2em; background: #ddf; }
|
|
pre code { font-size: 1.1em; background: #ddf; }
|
|
</style>
|
|
|
|
</head>
|
|
|
|
<p style="text-align:center">
|
|
<a href="master-toc.html">master TOC</a>
|
|
|
|
|
<a href="master-toc.html#user">chapter TOC</a>
|
|
|
|
|
<a href="support.html">support</a>
|
|
</p>
|
|
|
|
|
|
<h1>what users (not admins) need to know about gitolite</h1>
|
|
|
|
<p>...written for the one guy in the world no one will think of as "just a normal
|
|
user" ;-)</p>
|
|
|
|
<p>This document has some text, and a lot of links. Most of this info <em>is</em>
|
|
available in the rest of the documentation, but it's scattered and sparse.
|
|
Collecting all of it, or at least links to it, in one place sounds useful.</p>
|
|
|
|
<p><a name="user_accessing_gitolite_"></a></p>
|
|
|
|
<h2>accessing gitolite</h2>
|
|
|
|
<p>The most common setup is based on ssh, where your admin asks you to send him
|
|
your public key, and uses that to setup your access.</p>
|
|
|
|
<p>Your actual access is either a git command (like <code>git clone
|
|
git@server:reponame</code>, and we won't be discussing these any more in this
|
|
document), or an ssh command (like <code>ssh git@server info</code>).</p>
|
|
|
|
<p>Note that you do <em>not</em> get a shell on the server -- the whole point of
|
|
gitolite is to prevent that!</p>
|
|
|
|
<p><a name="user_always_available_commands_"></a></p>
|
|
|
|
<h2>always available commands</h2>
|
|
|
|
<p>The only command that is <em>always</em> available to every user is the <a href="info_expand.html#info" title="the "info" command"><code>info</code>
|
|
command</a>, which tells you what version of gitolite and git are on the
|
|
server, and what repositories you have access to. The list of repos is very
|
|
useful if you have doubts about the spelling of some new repo that you know
|
|
was setup.</p>
|
|
|
|
<p><a name="user_digression_two_kinds_of_repos_"></a></p>
|
|
|
|
<h2>digression: two kinds of repos</h2>
|
|
|
|
<p>Gitolite has two kinds of repos. Normal repos are specified by their full
|
|
names in the config file. "Wildcard" repos are specified by a regex in the
|
|
config file. Try the <a href="info_expand.html#info" title="the "info" command"><code>info</code> command</a> and see if it shows any lines
|
|
that look like regex patterns, (with a "C" permission in addition to the "R"
|
|
and the "W").</p>
|
|
|
|
<p>If you see any, it means you are allowed to create brand new repos whose names
|
|
fit that pattern. When you create such a repo, your "ownership" of it (as far
|
|
as gitolite is concerned) is <em>automatically</em> recorded by creating a 1-line
|
|
file called "gl-creater" (note spelling!) in the repo directory, with just
|
|
your gitolite userid in it.</p>
|
|
|
|
<p>This is for new repos you create. But for repos that already existed and were
|
|
migrated into gitolite by the admin, the admin has to manually create that
|
|
"gl-creater" file, otherwise you won't be able to execute certain commands
|
|
that you otherwise might have access to.</p>
|
|
|
|
<p>"Wildrepos" is an optional feature of gitolite that the admin has to
|
|
explicitly enable.</p>
|
|
|
|
<p><a name="user_commands_only_available_with_wildrepos_on_"></a></p>
|
|
|
|
<h2>commands only available with "wildrepos" on</h2>
|
|
|
|
<p><a name="user_listing_repos_you_created_"></a></p>
|
|
|
|
<h3>listing repos you created</h3>
|
|
|
|
<p>The info command will not show you your own wildcard repos. To get that list,
|
|
try the <a href="info_expand.html#expand" title="the "expand" command"><code>expand</code> command</a>.</p>
|
|
|
|
<p><a name="user_set_get_additional_permissions_for_repos_you_created_"></a></p>
|
|
|
|
<h3>set/get additional permissions for repos you created</h3>
|
|
|
|
<p>The gitolite config may have several permissions lines for your repo, like so:</p>
|
|
|
|
<pre><code>repo pub/CREATOR/..*
|
|
RW+ = CREATOR
|
|
RW = user1 user2
|
|
R = user3
|
|
</code></pre>
|
|
|
|
<p>If that's all it had, you really can't do much. Any changes to access must be
|
|
done by the administrator. (Note that "CREATOR" is a reserved word that gets
|
|
expanded to your userid in some way, so the admin can literally add just the
|
|
first two lines, and <em>every</em> authenticated user now has his own personal repo
|
|
namespace, starting with <code>pub/<username>/</code>).</p>
|
|
|
|
<p>To give some flexibility to users, the admin could add rules like this:</p>
|
|
|
|
<pre><code> RW = WRITERS
|
|
R = READERS
|
|
</code></pre>
|
|
|
|
<p>(he could also add other roles but then he needs to read the documentation).</p>
|
|
|
|
<p>Once he does this, you can then use the <a href="setperms.html" title="handing out rights to wildcard-matched repos"><code>setperms</code> command</a> to set
|
|
permissions for other users by specifying which users are in the list of
|
|
"READERS", and which in "WRITERS". That same section also talks about the
|
|
<code>getperms</code> command as well.</p>
|
|
|
|
<p>If you think of READERS and WRITERS as "roles", it will help. You can't
|
|
change what access a role has, but you <em>can</em> say which users have that role.</p>
|
|
|
|
<p><strong>Note</strong>: there isn't a way for you to see the actual rule set unless you're
|
|
given read access to the special 'gitolite-admin' repo. Sorry. The idea is
|
|
that your admin will tell you what "roles" he added into rules for your repos,
|
|
and what permissions those roles have.</p>
|
|
|
|
<p><a name="setdesc"></a></p>
|
|
|
|
<h3>adding a description to repos you created</h3>
|
|
|
|
<p>The <code>setdesc</code> and <code>getdesc</code> commands work similarly to the <code>setperms</code> and
|
|
<code>getperms</code> commands. You just say</p>
|
|
|
|
<pre><code>echo "some description here" | ssh git@server setdesc pub/<yourname>/<your_reponame>
|
|
</code></pre>
|
|
|
|
<p>and if you want to check you just say</p>
|
|
|
|
<pre><code>ssh git@server getdesc pub/<yourname>/<your_reponame>
|
|
</code></pre>
|
|
|
|
<p><a name="user_site_local_commands_"></a></p>
|
|
|
|
<h2>"site-local" commands</h2>
|
|
|
|
<p>The main purpose of gitolite is to prevent you from getting a shell. But
|
|
there are commands that you often need to run on the server (i.e., cannot be
|
|
done by pushing something to a repo).</p>
|
|
|
|
<p>To enable this, gitolite allows the admin to setup scripts in a special
|
|
directory that users can then run. Gitolite comes with a set of working
|
|
scripts (in "contrib/adc") that your admin may install, or may use as a
|
|
starting point for his own, if he chooses.</p>
|
|
|
|
<p>Think of these commands as equivalent to those in <code>COMMAND_DIR</code> in <code>man
|
|
git-shell</code>.</p>
|
|
|
|
<p>Most of the shipped ADCs are briefly described <a href="shipped_ADCs.html" title="brief descriptions of the shipped ADCs (admin-defined commands)">here</a>, with links
|
|
to more details if available. However, <strong>please understand</strong> that these
|
|
commands may not be available, or their behaviour may have been changed to
|
|
suit local requirements, and of course new ones may have been added. You'll
|
|
have to ask your local admin for answers, not me!</p>
|