Autogenerated HTML docs for v1.5.0.3-310-g05ef5

1 files changed, 105 insertions, 47 deletions

diff --git a/git-receive-pack.html b/git-receive-pack.html
index 6c73b5d94..d02c4acfb 100644
--- a/git-receive-pack.html
+++ b/git-receive-pack.html
@@ -286,68 +286,126 @@ repository.  For pull operations, see <em>git-fetch-pack</em>.</p>
 (heads/tags) on the remote end (strictly speaking, it is the

 local end receive-pack runs, but to the user who is sitting at

 the send-pack end, it is updating the remote.  Confused?)</p>

+<p>There are other real-world examples of using update and

+post-update hooks found in the Documentation/howto directory.</p>

+<p>git-receive-pack honours the receive.denyNonFastForwards config

+option, which tells it if updates to a ref should be denied if they

+are not fast-forwards.</p>

+</div>

+<h2>OPTIONS</h2>

+<div class="sectionbody">

+<dl>

+<dt>

+&lt;directory&gt;

+</dt>

+<dd>

+<p>

+        The repository to sync into.

+</p>

+</dd>

+</dl>

+</div>

+<h2>pre-receive Hook</h2>

+<div class="sectionbody">

+<p>Before any ref is updated, if $GIT_DIR/hooks/pre-receive file exists

+and is executable, it will be invoked once, with three parameters

+per ref to be updated:</p>

+<div class="literalblock">

+<div class="content">

+<pre><tt>$GIT_DIR/hooks/pre-receive (refname sha1-old sha1-new)+</tt></pre>

+</div></div>

+<p>The refname parameter is relative to $GIT_DIR; e.g. for the master

+head this is "refs/heads/master".  The two sha1 arguments after

+each refname are the object names for the refname before and after

+sha1-old and sha1-new should be valid objects in the repository.</p>

+<p>This hook is called before any refname is updated and before any

+fast-forward checks are performed.</p>

+<p>If the pre-receive hook exits with a non-zero exit status no updates

+will be performed, and the update, post-receive and post-update

+hooks will not be invoked either.  This can be useful to quickly

+bail out if the update is not to be supported.</p>

+</div>

+<h2>update Hook</h2>

+<div class="sectionbody">

 <p>Before each ref is updated, if $GIT_DIR/hooks/update file exists

-and executable, it is called with three parameters:</p>

+and is executable, it is invoked once per ref, with three parameters:</p>

 <div class="literalblock">

 <div class="content">

 <pre><tt>$GIT_DIR/hooks/update refname sha1-old sha1-new</tt></pre>

 </div></div>

-<p>The refname parameter is relative to $GIT_DIR; e.g. for the

-master head this is "refs/heads/master".  Two sha1 are the

-object names for the refname before and after the update.  Note

-that the hook is called before the refname is updated, so either

-should match what is recorded in refname.</p>

-<p>The hook should exit with non-zero status if it wants to

-disallow updating the named ref.  Otherwise it should exit with

-zero.</p>

-<p>Using this hook, it is easy to generate mails on updates to

-the local repository. This example script sends a mail with

-the commits pushed to the repository:</p>

+<p>The refname parameter is relative to $GIT_DIR; e.g. for the master

+head this is "refs/heads/master".  The two sha1 arguments are

+the object names for the refname before and after the update.

+Note that the hook is called before the refname is updated,

+or it should match what is recorded in refname.</p>

+<p>The hook should exit with non-zero status if it wants to disallow

+updating the named ref.  Otherwise it should exit with zero.</p>

+<p>Successful execution (a zero exit status) of this hook does not

+ensure the ref will actully be updated, it is only a prerequisite.

+As such it is not a good idea to send notices (e.g. email) from

+this hook.  Consider using the post-receive hook instead.</p>

+</div>

+<h2>post-receive Hook</h2>

+<div class="sectionbody">

+<p>After all refs were updated (or attempted to be updated), if any

+ref update was successful, and if $GIT_DIR/hooks/post-receive

+file exists and is executable, it will be invoke once with three

+parameters for each successfully updated ref:</p>

+<div class="literalblock">

+<div class="content">

+<pre><tt>$GIT_DIR/hooks/post-receive (refname sha1-old sha1-new)+</tt></pre>

+</div></div>

+<p>The refname parameter is relative to $GIT_DIR; e.g. for the master

+head this is "refs/heads/master".  The two sha1 arguments after

+each refname are the object names for the refname before and after

+the update.  Refs that were created will have sha1-old equal to

+the repository.</p>

+<p>Using this hook, it is easy to generate mails describing the updates

+to the repository.  This example script sends one mail message per

+ref listing the commits pushed to the repository:</p>

 <div class="literalblock">

 <div class="content">

 <pre><tt>#!/bin/sh

 # mail out commit update information.

-if expr "$2" : '0*$' &gt;/dev/null

-then

-        echo "Created a new ref, with the following commits:"

-        git-rev-list --pretty "$2"

-else

-        echo "New commits:"

-        git-rev-list --pretty "$3" "^$2"

-fi |

-mail -s "Changes to ref $1" commit-list@mydomain

+while test $# -gt 0

+do

+        if expr "$2" : '0*$' &gt;/dev/null

+        then

+                echo "Created a new ref, with the following commits:"

+                git-rev-list --pretty "$2"

+        else

+                echo "New commits:"

+                git-rev-list --pretty "$3" "^$2"

+        fi |

+        mail -s "Changes to ref $1" commit-list@mydomain

+        shift; shift; shift; # discard this ref's args

+done

 exit 0</tt></pre>

 </div></div>

-<p>Another hook $GIT_DIR/hooks/post-update, if exists and

-executable, is called with the list of refs that have been

-updated.  This can be used to implement repository wide cleanup

-task if needed.  The exit code from this hook invocation is

-ignored; the only thing left for git-receive-pack to do at that

-point is to exit itself anyway.  This hook can be used, for

-example, to run "git-update-server-info" if the repository is

-packed and is served via a dumb transport.</p>

+<p>The exit code from this hook invocation is ignored, however a

+non-zero exit code will generate an error message.</p>

+<p>Note that it is possible for refname to not have sha1-new when this

+hook runs.  This can easily occur if another user modifies the ref

+after it was updated by receive-pack, but before the hook was able

+to evaluate it.  It is recommended that hooks rely on sha1-new

+rather than the current value of refname.</p>

+</div>

+<h2>post-update Hook</h2>

+<div class="sectionbody">

+<p>After all other processing, if at least one ref was updated, and

+if $GIT_DIR/hooks/post-update file exists and is executable, then

+post-update will called with the list of refs that have been updated.

+This can be used to implement any repository wide cleanup tasks.</p>

+<p>The exit code from this hook invocation is ignored; the only thing

+left for git-receive-pack to do at that point is to exit itself

+anyway.</p>

+<p>This hook can be used, for example, to run "git-update-server-info"

+if the repository is packed and is served via a dumb transport.</p>

 <div class="literalblock">

 <div class="content">

 <pre><tt>#!/bin/sh

 exec git-update-server-info</tt></pre>

 </div></div>

-<p>There are other real-world examples of using update and

-post-update hooks found in the Documentation/howto directory.</p>

-<p>git-receive-pack honours the receive.denyNonFastforwards flag, which

-tells it if updates to a ref should be denied if they are not fast-forwards.</p>

-</div>

-<h2>OPTIONS</h2>

-<div class="sectionbody">

-<dl>

-<dt>

-&lt;directory&gt;

-</dt>

-<dd>

-<p>

-        The repository to sync into.

-</p>

-</dd>

-</dl>

 </div>

 <h2>SEE ALSO</h2>

 <div class="sectionbody">

@@ -367,7 +425,7 @@ tells it if updates to a ref should be denied if they are not fast-forwards.</p>
 </div>

 <div id="footer">

 <div id="footer-text">

-Last updated 19-Jan-2007 00:37:30 UTC

+Last updated 08-Mar-2007 02:42:38 UTC

 </div>

 </div>

 </body>