Permalink
Browse files

autogenerated from git-notes c2117bb and gitolite-doc 9d1a3dd; do not…

… edit
  • Loading branch information...
1 parent 4e43c38 commit 6005a6c7d83e07c3292c1ec79b705afe3aaf6145 @sitaramc committed Mar 5, 2013
View
8 gitolite/cust.html
@@ -109,7 +109,7 @@
<ul>
<li><em>Commands</em> can be run from the shell command line. Among those, the ones
-listed in the COMMANDS hash of the rc file can also be run remotely.
+in the ENABLE list in the rc file can also be run remotely.
</li>
<li><em>Hooks</em> are standard git hooks.
</li>
@@ -226,7 +226,7 @@
Naturally, a remote user will see a much smaller list than the server user.</p>
<p>You allow a command to be run from remote clients by adding its name to (or
-uncommenting it if it's already added but commented out) the COMMANDS hash in
+uncommenting it if it's already added but commented out) the ENABLE list in
the <a href="rc.html">rc</a> file.</p>
<h3><a name="hooks"></a> hooks and gitolite</h3>
@@ -259,8 +259,8 @@
<p>If you want to write your own sugar scripts, please read the "your own sugar"
section in <a href="dev-notes.html">dev-notes</a> first then email me.</p>
-<p>You enable a sugar script by adding it to the <code>SYNTACTIC_SUGAR</code> list in the rc
-file.</p>
+<p>You enable a sugar script by uncommenting the feature name in the ENABLE list
+in the rc file.</p>
<h3>triggers</h3>
View
7 gitolite/g2migr.html
@@ -137,10 +137,9 @@
<li><p><code>GL_NO_DAEMON_NO_GITWEB</code> <strong>dropped</strong>, <strong>requires presetting</strong>. Default
will clobber your projects.list file and git-daemon-export-ok files.</p>
-<p>Comment out the appropriate lines in the rc file, in the <code>POST_COMPILE</code>
-<em>and</em> the <code>POST_CREATE</code> trigger sections. As a bonus, gitweb and daemon
-can now be separately disabled, instead of both being tied to the same
-setting.</p></li>
+<p>Comment out the 'daemon' and 'gitweb' lines in the ENABLE list in the rc
+file. As you can see, gitweb and daemon can now be separately disabled,
+instead of both being tied to the same setting.</p></li>
<li><p><code>GL_NO_SETUP_AUTHKEYS</code> <strong>dropped</strong>, <strong>requires presetting</strong>. Default will
clobber your authkeys file.</p>
View
15 gitolite/g3why.html
@@ -110,15 +110,12 @@
write your own, though they do have to be in perl (because they're not
standalone programs).</p>
-<p>Once the code is written and placed in the right place, all a site has to
-do to enable it is to uncomment some lines in the rc file:</p>
-
-<pre><code># these will run in sequence during the conf file parse
-SYNTACTIC_SUGAR =&gt;
- [
- # 'continuation-lines',
- # 'keysubdirs-as-groups',
- &lt;etc&gt;
+<p>Once the code is written and placed in the right place, all you have to do
+to enable it is to uncomment some lines in the ENABLE list in the rc file:</p>
+
+<pre><code># 'continuation-lines',
+# 'keysubdirs-as-groups',
+&lt;etc&gt;
</code></pre></li>
<li><p>roll your own</p>
View
78 gitolite/gitolite.html
@@ -1666,7 +1666,13 @@
<h2><a name="rc-rc"></a> the "rc" file (<code>$HOME/.gitolite.rc</code>)</h2>
-<p><strong>NOTE</strong>: if you're migrating from g2, there are some settings that MUST be
+<p><strong>IMPORTANT</strong>: if you have a v3.0-v3.3 rc file it will still work. In fact
+internally the v3.4 rc file data gets converted to the v3.3 format. So just
+because you upgraded gitolite doesn't mean you have to change your rc file!</p>
+
+<p><strong>v3.3 or before</strong>: <a href="rc-33.html">this</a> is the document you need.</p>
+
+<p><strong>NOTE 2</strong>: if you're migrating from g2, there are some settings that MUST be
dealt with <strong>before</strong> running <code>gitolite setup</code>; please read the
<a href="gitolite.html#migr-migr">migration</a> page and linked pages, and especially the one on "presetting
the rc file"</p>
@@ -1685,11 +1691,11 @@
gitolite. As you can see there are 3 types of variables in it:</p>
<ul>
-<li>simple variables (like <code>UMASK</code>)
+<li>a lot of simple variables (like <code>UMASK</code>, <code>GIT_CONFIG_KEYS</code>, etc)
</li>
-<li>lists (like <code>POST_COMPILE</code>, <code>POST_CREATE</code>)
+<li>a hash or two (like <code>ROLES</code>)
</li>
-<li>hashes (like <code>ROLES</code>, <code>COMMANDS</code>)
+<li>and one large list of features to be enabled (<code>ENABLE</code>)
</li>
</ul>
@@ -2779,11 +2785,17 @@
<p>Back on your workstation:</p>
<ul>
-<li><p><a href="gitolite.html#repos-repos">Add them</a> to conf/gitolite.conf in your clone of the admin repo,
-then commit and push the change.</p>
+<li><p>If the repos are normal repos, <a href="gitolite.html#repos-repos">add them</a> to conf/gitolite.conf in
+your clone of the admin repo, then commit and push the change.</p>
+
+<p>If the repos are <a href="gitolite.html#wild-wild">wildcard</a> repos that already match some pattern in
+the conf file, you need to manually create the gl-creator file, like so:</p>
-<p>If the repos are already covered by some <a href="gitolite.html#wild-wild">wild</a> pattern, this is
-optional.</p></li>
+<pre><code>echo username &gt; ~/repositories/path/to/repo.git/gl-creator
+</code></pre>
+
+<p>I haven't yet found this to be common enough to bother wrapping it in a
+nice interface or command.</p></li>
</ul>
<h3><a name="rare-moving"></a> moving servers</h3>
@@ -3032,7 +3044,7 @@
<ul>
<li><em>Commands</em> can be run from the shell command line. Among those, the ones
-listed in the COMMANDS hash of the rc file can also be run remotely.
+in the ENABLE list in the rc file can also be run remotely.
</li>
<li><em>Hooks</em> are standard git hooks.
</li>
@@ -3149,7 +3161,7 @@
Naturally, a remote user will see a much smaller list than the server user.</p>
<p>You allow a command to be run from remote clients by adding its name to (or
-uncommenting it if it's already added but commented out) the COMMANDS hash in
+uncommenting it if it's already added but commented out) the ENABLE list in
the <a href="gitolite.html#rc-rc">rc</a> file.</p>
<h4><a name="cust-hooks"></a> hooks and gitolite</h4>
@@ -3182,8 +3194,8 @@
<p>If you want to write your own sugar scripts, please read the "your own sugar"
section in <a href="gitolite.html#dev-notes-dev-notes">dev-notes</a> first then email me.</p>
-<p>You enable a sugar script by adding it to the <code>SYNTACTIC_SUGAR</code> list in the rc
-file.</p>
+<p>You enable a sugar script by uncommenting the feature name in the ENABLE list
+in the rc file.</p>
<h4>triggers</h4>
@@ -3416,7 +3428,7 @@
<p>Here's how:</p>
<ol>
-<li><p>enable 'partial-copy' in the <code>PRE_GIT</code> section in the rc file.</p></li>
+<li><p>enable 'partial-copy' in the ENABLE list in the rc file.</p></li>
<li><p>for each repo "foo" which has secret branches that a certain set of
developers (we'll use a group called <code>@temp-emp</code> as an example) are not
supposed to see, do this:</p>
@@ -4009,7 +4021,8 @@
<p>Gitolite fires off external commands at 7 different times. The <a href="gitolite.html#rc-rc">rc</a> file
specifies what commands to run at each trigger point, but for illustration,
-here's an excerpt:</p>
+here's an excerpt. <strong>Note that as of v3.4, this is <em>not</em> how the rc file
+looks like externally; please see the <a href="gitolite.html#rc-rc">rc file docs</a> for more</strong>.</p>
<pre><code>%RC = (
@@ -4081,7 +4094,7 @@
<ol>
<li><p>any arguments mentioned in the rc file (for an example, see the renice
-command in the PRE_GIT trigger sequence),</p></li>
+command)</p></li>
<li><p>the name of the trigger as a string (example, <code>"POST_COMPILE"</code>), so you
can call the same program from multiple triggers and it can know where it
was called from,</p></li>
@@ -4673,11 +4686,7 @@
<pre><code>SHELL_USERS_LIST =&gt; "$ENV{HOME}/.gitolite.shell-users",
</code></pre></li>
-<li><p>add the line <code>'Shell::input',</code> to the <code>INPUT</code> list in the rc file. This
-must be the first item on the list (possibly preceded by CpuTime, if
-you're using that).</p></li>
-<li><p>add the line <code>'post-compile/ssh-authkeys-shell-users',</code> to the
-<code>POST_COMPILE</code> list, <em>after</em> the <code>'post-compile/ssh-authkeys',</code> line.</p></li>
+<li><p>enable the trigger by uncommenting the 'Shell' line in the ENABLE list.</p></li>
</ul>
<p>Then run <code>gitolite compile; gitolite trigger POST_COMPILE</code> or push a dummy
@@ -4692,12 +4701,12 @@
<p>However, if you replace</p>
-<pre><code>'post-compile/ssh-authkeys',
+<pre><code>'ssh-authkeys',
</code></pre>
-<p>in the <code>POST_COMPILE</code> trigger list in the rc file with</p>
+<p>in the ENABLE list with</p>
-<pre><code>'post-compile/ssh-authkeys --key-file-name',
+<pre><code>'ssh-authkeys --key-file-name',
</code></pre>
<p>then an extra argument is added after the username in the "command" variable
@@ -5573,15 +5582,12 @@
write your own, though they do have to be in perl (because they're not
standalone programs).</p>
-<p>Once the code is written and placed in the right place, all a site has to
-do to enable it is to uncomment some lines in the rc file:</p>
+<p>Once the code is written and placed in the right place, all you have to do
+to enable it is to uncomment some lines in the ENABLE list in the rc file:</p>
-<pre><code># these will run in sequence during the conf file parse
-SYNTACTIC_SUGAR =&gt;
- [
- # 'continuation-lines',
- # 'keysubdirs-as-groups',
- &lt;etc&gt;
+<pre><code># 'continuation-lines',
+# 'keysubdirs-as-groups',
+&lt;etc&gt;
</code></pre></li>
<li><p>roll your own</p>
@@ -5837,8 +5843,7 @@
bit more detail on what took time.</p></li>
<li><p>If you don't use gitweb or git-daemon, or use them but are perfectly happy
to control access to them from outside gitolite, you can comment out the
-corresponding lines in the POST_CREATE and POST_COMPILE trigger lists in
-the rc file.</p></li>
+corresponding lines in the ENABLE list the rc file.</p></li>
<li><p>If you can't get rid of those scripts, and they are still taking too long,
you can make them run in the background. They'll eventually finish but
the user doesn't have to wait. See src/triggers/bg. <em>This should not
@@ -6088,10 +6093,9 @@
<li><p><code>GL_NO_DAEMON_NO_GITWEB</code> <strong>dropped</strong>, <strong>requires presetting</strong>. Default
will clobber your projects.list file and git-daemon-export-ok files.</p>
-<p>Comment out the appropriate lines in the rc file, in the <code>POST_COMPILE</code>
-<em>and</em> the <code>POST_CREATE</code> trigger sections. As a bonus, gitweb and daemon
-can now be separately disabled, instead of both being tied to the same
-setting.</p></li>
+<p>Comment out the 'daemon' and 'gitweb' lines in the ENABLE list in the rc
+file. As you can see, gitweb and daemon can now be separately disabled,
+instead of both being tied to the same setting.</p></li>
<li><p><code>GL_NO_SETUP_AUTHKEYS</code> <strong>dropped</strong>, <strong>requires presetting</strong>. Default will
clobber your authkeys file.</p>
View
4 gitolite/locking.html
@@ -94,8 +94,8 @@
<h2>admin/setup</h2>
-<p>First, someone with shell access to the server must add 'lock' to the
-"COMMANDS" list in the rc file.</p>
+<p>First, someone with shell access to the server must add 'lock' to the ENABLE
+list in the rc file.</p>
<p>Next, the gitolite.conf file should have something like this:</p>
View
2 gitolite/non-core.html
@@ -294,7 +294,7 @@
<p>Here's how:</p>
<ol>
-<li><p>enable 'partial-copy' in the <code>PRE_GIT</code> section in the rc file.</p></li>
+<li><p>enable 'partial-copy' in the ENABLE list in the rc file.</p></li>
<li><p>for each repo "foo" which has secret branches that a certain set of
developers (we'll use a group called <code>@temp-emp</code> as an example) are not
supposed to see, do this:</p>
View
3 gitolite/perf.html
@@ -67,8 +67,7 @@
bit more detail on what took time.</p></li>
<li><p>If you don't use gitweb or git-daemon, or use them but are perfectly happy
to control access to them from outside gitolite, you can comment out the
-corresponding lines in the POST_CREATE and POST_COMPILE trigger lists in
-the rc file.</p></li>
+corresponding lines in the ENABLE list the rc file.</p></li>
<li><p>If you can't get rid of those scripts, and they are still taking too long,
you can make them run in the background. They'll eventually finish but
the user doesn't have to wait. See src/triggers/bg. <em>This should not
View
14 gitolite/rare.html
@@ -74,11 +74,17 @@
<p>Back on your workstation:</p>
<ul>
-<li><p><a href="repos.html">Add them</a> to conf/gitolite.conf in your clone of the admin repo,
-then commit and push the change.</p>
+<li><p>If the repos are normal repos, <a href="repos.html">add them</a> to conf/gitolite.conf in
+your clone of the admin repo, then commit and push the change.</p>
-<p>If the repos are already covered by some <a href="wild.html">wild</a> pattern, this is
-optional.</p></li>
+<p>If the repos are <a href="wild.html">wildcard</a> repos that already match some pattern in
+the conf file, you need to manually create the gl-creator file, like so:</p>
+
+<pre><code>echo username &gt; ~/repositories/path/to/repo.git/gl-creator
+</code></pre>
+
+<p>I haven't yet found this to be common enough to bother wrapping it in a
+nice interface or command.</p></li>
</ul>
<h2><a name="moving"></a> moving servers</h2>
View
166 gitolite/rc-33.html
@@ -0,0 +1,166 @@
+
+<head>
+ <title>the v3.0 to v3.3 "rc" file (`$HOME/.gitolite.rc`)</title>
+<style>
+ body { background: #fff; text-color: #000; margin-left: 40px; font-size: 0.9em; font-family: sans-serif; max-width: 800px; }
+ h1 { background: #ffb; text-color: #000; margin-left: -30px; border-top: 5px solid #ccc; }
+ h2 { background: #ffb; text-color: #000; margin-left: -20px; border-top: 3px solid #ddd; }
+ h3 { background: #ffb; text-color: #000; margin-left: -10px; }
+ h4 { background: #ffb; text-color: #000; }
+ code { font-size: 1.1em; background: #ddf; text-color: #000; }
+ pre { margin-left: 2em; background: #ddf; text-color: #000; }
+ pre code { font-size: 1.1em; background: #ddf; text-color: #000; }
+</style>
+<style>
+ body{counter-reset: section}
+ h1{counter-reset: sub-section}
+ h2{counter-reset: composite}
+ h3{counter-reset: detail}
+
+ h1:before {
+ counter-increment: section;
+ content: counter(section) ". ";
+ }
+ h2:before {
+ counter-increment: sub-section;
+ content: counter(section) "." counter(sub-section) ". ";
+ }
+ h3:before {
+ counter-increment: composite;
+ content: counter(section) "." counter(sub-section) "." counter(composite) ". ";
+ }
+ h4:before {
+ counter-increment: detail;
+ content: counter(section) "." counter(sub-section) "." counter(composite) "." counter(detail) ". ";
+ }
+</style>
+</head>
+
+<p style="text-align:center">
+ <a href="master-toc.html">master TOC</a>
+|
+ <a href="index.html">main page</a>
+|
+ <a href="gitolite.html">single-page</a>
+|
+ <a href="index.html#license">license</a>
+</p>
+<p style="text-align:center">
+<font color="gray">This is for gitolite "g3"; for older (v2.x) documentation click <a href="http://sitaramc.github.com/gitolite/g2/master-toc.html">here</a></font>
+</p>
+<h1>the v3.0 to v3.3 "rc" file (<code>$HOME/.gitolite.rc</code>)</h1>
+
+<p><strong>NOTE 1</strong>: if you're using v3.4 and above, see <a href="rc.html">this</a>.</p>
+
+<p><strong>NOTE 2</strong>: if you're migrating from g2, there are some settings that MUST be
+dealt with <strong>before</strong> running <code>gitolite setup</code>; please read the
+<a href="migr.html">migration</a> page and linked pages, and especially the one on "presetting
+the rc file"</p>
+
+<hr />
+
+<p>The rc file for g3 is <em>quite</em> different from that of g2.</p>
+
+<p>As before, it is designed to be the only thing unique to your site for most
+setups. What is new is that it is easy to extend it when new needs come up,
+without having to touch core gitolite.</p>
+
+<p>The rc file is perl code, but you do NOT need to know perl to edit it. Just
+mind the commas, use single quotes unless you know what you're doing, and make
+sure the brackets and braces stay matched up!</p>
+
+<p>Please look at the <code>~/.gitolite.rc</code> file that gets installed when you setup
+gitolite. As you can see there are 3 types of variables in it:</p>
+
+<ul>
+<li>simple variables (like <code>UMASK</code>)
+</li>
+<li>lists (like <code>POST_COMPILE</code>, <code>POST_CREATE</code>)
+</li>
+<li>hashes (like <code>ROLES</code>, <code>COMMANDS</code>)
+</li>
+</ul>
+
+<p>While some of the variables are documented in this file, many of them are not.
+Their purposes are to be found in each of their individual documentation files
+around; start with <a href="cust.html">customising gitolite</a>. If a setting is used by an
+external command then running that command with '-h' may give you additional
+information.</p>
+
+<h2>specific variables</h2>
+
+<ul>
+<li><p><code>$UMASK</code>, octal, default <code>0077</code></p>
+
+<p>The default UMASK that gitolite uses makes all the repos and their
+contents have <code>rwx------</code> permissions. People who want to run gitweb
+realise that this will not do.</p>
+
+<p>The correct way to deal with this is to give this variable a value like
+<code>0027</code> (note the syntax: the leading 0 is required), and then make the
+user running the webserver (apache, www-data, whatever) a member of the
+'git' group.</p>
+
+<p>If you've already installed gitolite then existing files will have to be
+fixed up manually (for a umask or 0027, that would be <code>chmod -R g+rX</code>).
+This is because umask only affects permissions on newly created files, not
+existing ones.</p></li>
+<li><p><code>$GIT_CONFIG_KEYS</code>, string, default empty</p>
+
+<p>This setting allows the repo admin to define acceptable gitconfig keys.</p>
+
+<p>Gitolite allows you to set git config values using the "config" keyword;
+see <a href="git-config.html">here</a> for details and syntax.</p>
+
+<p>However, if you are in an installation where the repo admin does not (and
+should not) have shell access to the server, then allowing him to set
+arbitrary repo config options <em>may</em> be a security risk -- some config
+settings allow executing arbitrary commands!</p>
+
+<p>You have 3 choices. By default <code>$GIT_CONFIG_KEYS</code> is left empty, which
+completely disables this feature (meaning you cannot set git configs via
+the repo config).</p>
+
+<p>The second choice is to give it a space separated list of settings you
+consider safe. (These are actually treated as a set of <a href="regex.html">regular
+expression</a> patterns, and any one of them must match).</p>
+
+<p>For example:</p>
+
+<pre><code>$GIT_CONFIG_KEYS = 'core\.logAllRefUpdates core\..*compression';
+</code></pre>
+
+<p>Each pattern should match the <em>whole</em> key (in other words, there
+is an implicit <code>^</code> at the start of each pattern, and a <code>$</code> at the
+end).</p>
+
+<p>The third choice (which you may have guessed already if you're familiar
+with regular expressions) is to allow anything and everything:
+<code>$GIT_CONFIG_KEYS = '.*';</code></p></li>
+<li><p><code>ROLES</code>, hash, default keys 'READERS' and 'WRITERS'</p>
+
+<p>This specifies the role names allowed to be used by users running the
+<a href="user.html#perms">perms</a> command. The <a href="wild.html">wild</a> repos doc has more info on roles.</p></li>
+<li><p><code>DEFAULT_ROLE_PERMS</code>, string, default undef</p>
+
+<p>This sets default wildcard permissions for newly created wildcard repos.</p>
+
+<p>If set, this value will be used as the default role permissions for new
+wildcard repositories. The user can change this value with the perms
+command as desired after repository creation; it is only a default.</p>
+
+<p>Please be aware this is potentially a multi-line variable. In most
+setups, it will be left undefined. Some installations may benefit from
+setting it to <code>READERS @all</code>.</p>
+
+<p>If you want multiple roles to be assigned by default, here is how. Note
+double quotes this time, due to the embedded newline, which in turn
+require the '@' to be escaped:</p>
+
+<pre><code>DEFAULT_ROLE_PERMS =&gt; "READERS \@all\nWRITERS \@senior_devs",
+</code></pre></li>
+<li><p><code>LOCAL_CODE</code>, string</p>
+
+<p>This is described in more detail <a href="cust.html#localcode">here</a>. Please be aware
+<strong>this must be a FULL path</strong>, not a relative path.</p></li>
+</ul>
View
14 gitolite/rc.html
@@ -50,7 +50,13 @@
</p>
<h1>the "rc" file (<code>$HOME/.gitolite.rc</code>)</h1>
-<p><strong>NOTE</strong>: if you're migrating from g2, there are some settings that MUST be
+<p><strong>IMPORTANT</strong>: if you have a v3.0-v3.3 rc file it will still work. In fact
+internally the v3.4 rc file data gets converted to the v3.3 format. So just
+because you upgraded gitolite doesn't mean you have to change your rc file!</p>
+
+<p><strong>v3.3 or before</strong>: <a href="rc-33.html">this</a> is the document you need.</p>
+
+<p><strong>NOTE 2</strong>: if you're migrating from g2, there are some settings that MUST be
dealt with <strong>before</strong> running <code>gitolite setup</code>; please read the
<a href="migr.html">migration</a> page and linked pages, and especially the one on "presetting
the rc file"</p>
@@ -71,11 +77,11 @@
gitolite. As you can see there are 3 types of variables in it:</p>
<ul>
-<li>simple variables (like <code>UMASK</code>)
+<li>a lot of simple variables (like <code>UMASK</code>, <code>GIT_CONFIG_KEYS</code>, etc)
</li>
-<li>lists (like <code>POST_COMPILE</code>, <code>POST_CREATE</code>)
+<li>a hash or two (like <code>ROLES</code>)
</li>
-<li>hashes (like <code>ROLES</code>, <code>COMMANDS</code>)
+<li>and one large list of features to be enabled (<code>ENABLE</code>)
</li>
</ul>
View
12 gitolite/sts.html
@@ -272,11 +272,7 @@
<pre><code>SHELL_USERS_LIST =&gt; "$ENV{HOME}/.gitolite.shell-users",
</code></pre></li>
-<li><p>add the line <code>'Shell::input',</code> to the <code>INPUT</code> list in the rc file. This
-must be the first item on the list (possibly preceded by CpuTime, if
-you're using that).</p></li>
-<li><p>add the line <code>'post-compile/ssh-authkeys-shell-users',</code> to the
-<code>POST_COMPILE</code> list, <em>after</em> the <code>'post-compile/ssh-authkeys',</code> line.</p></li>
+<li><p>enable the trigger by uncommenting the 'Shell' line in the ENABLE list.</p></li>
</ul>
<p>Then run <code>gitolite compile; gitolite trigger POST_COMPILE</code> or push a dummy
@@ -291,12 +287,12 @@
<p>However, if you replace</p>
-<pre><code>'post-compile/ssh-authkeys',
+<pre><code>'ssh-authkeys',
</code></pre>
-<p>in the <code>POST_COMPILE</code> trigger list in the rc file with</p>
+<p>in the ENABLE list with</p>
-<pre><code>'post-compile/ssh-authkeys --key-file-name',
+<pre><code>'ssh-authkeys --key-file-name',
</code></pre>
<p>then an extra argument is added after the username in the "command" variable
View
5 gitolite/triggers.html
@@ -73,7 +73,8 @@
<p>Gitolite fires off external commands at 7 different times. The <a href="rc.html">rc</a> file
specifies what commands to run at each trigger point, but for illustration,
-here's an excerpt:</p>
+here's an excerpt. <strong>Note that as of v3.4, this is <em>not</em> how the rc file
+looks like externally; please see the <a href="rc.html">rc file docs</a> for more</strong>.</p>
<pre><code>%RC = (
@@ -145,7 +146,7 @@
<ol>
<li><p>any arguments mentioned in the rc file (for an example, see the renice
-command in the PRE_GIT trigger sequence),</p></li>
+command)</p></li>
<li><p>the name of the trigger as a string (example, <code>"POST_COMPILE"</code>), so you
can call the same program from multiple triggers and it can know where it
was called from,</p></li>
View
BIN images/flow-CVCS.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN images/flow-DVCS.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN images/flow-Git.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN images/index-use-review-1.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN images/index-use-review-2.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN images/index-use-review-3.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN images/index-use-review-4.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit 6005a6c

Please sign in to comment.