<p>If the hook exits with non-zero status, none of the refs will be\r
updated. If the hook exits with zero, updating of individual refs can\r
still be prevented by the <a href="#update"><em>update</em></a> hook.</p>\r
-<p>If you want to report something to the <tt>git-send-pack</tt> on the other end,\r
-you can simply <tt>echo</tt> your messages.</p>\r
+<p>Both standard output and standard error output are forwarded to\r
+<tt>git-send-pack</tt> on the other end, so you can simply <tt>echo</tt> messages\r
+for the user.</p>\r
</div>\r
<h2><a id="update"></a>update</h2>\r
<div class="sectionbody">\r
<p>Another use suggested on the mailing list is to use this hook to\r
implement access control which is finer grained than the one\r
based on filesystem group.</p>\r
-<p>The standard output of this hook is sent to <tt>stderr</tt>, so if you\r
-want to report something to the <tt>git-send-pack</tt> on the other end,\r
-you can simply <tt>echo</tt> your messages.</p>\r
+<p>Both standard output and standard error output are forwarded to\r
+<tt>git-send-pack</tt> on the other end, so you can simply <tt>echo</tt> messages\r
+for the user.</p>\r
<p>The default <em>update</em> hook, when enabled—and with\r
<tt>hooks.allowunannotated</tt> config option turned on—prevents\r
unannotated tags to be pushed.</p>\r
It executes on the remote repository once after all the refs have\r
been updated.</p>\r
<p>This hook executes once for the receive operation. It takes no\r
-arguments, but gets the same information as the <tt>pre-receive</tt>\r
+arguments, but gets the same information as the\r
+<a href="#pre-receive"><em>pre-receive</em></a>\r
hook does on its standard input.</p>\r
<p>This hook does not affect the outcome of <tt>git-receive-pack</tt>, as it\r
is called after the real work is done.</p>\r
-<p>This supersedes the <a id="post-update"></a> hook in that it actually get's\r
-both old and new values of all the refs.</p>\r
-<p>If you want to report something to the <tt>git-send-pack</tt> on the\r
-other end, you can simply <tt>echo</tt> your messages.</p>\r
+<p>This supersedes the <a href="#post-update"><em>post-update</em></a> hook in that it get's\r
+both old and new values of all the refs in addition to their\r
+names.</p>\r
+<p>Both standard output and standard error output are forwarded to\r
+<tt>git-send-pack</tt> on the other end, so you can simply <tt>echo</tt> messages\r
+for the user.</p>\r
<p>The default <em>post-receive</em> hook is empty, but there is\r
a sample script <tt>post-receive-email</tt> provided in the <tt>contrib/hooks</tt>\r
directory in git distribution, which implements sending commit\r
the outcome of <tt>git-receive-pack</tt>.</p>\r
<p>The <em>post-update</em> hook can tell what are the heads that were pushed,\r
but it does not know what their original and updated values are,\r
-so it is a poor place to do log old..new.</p>\r
-<p>In general, <tt>post-receive</tt> hook is preferred when the hook needs\r
-to decide its acion on the status of the entire set of refs\r
-being updated, as this hook is called once per ref, with\r
-information only on a single ref at a time.</p>\r
+so it is a poor place to do log old..new. The\r
+<a href="#post-receive"><em>post-receive</em></a> hook does get both original and\r
+updated values of the refs. You might consider it instead if you need\r
+them.</p>\r
<p>When enabled, the default <em>post-update</em> hook runs\r
<tt>git-update-server-info</tt> to keep the information used by dumb\r
transports (e.g., HTTP) up-to-date. If you are publishing\r
a git repository that is accessible via HTTP, you should\r
probably enable this hook.</p>\r
<p>Both standard output and standard error output are forwarded to\r
-<tt>git-send-pack</tt> on the other end.</p>\r
+<tt>git-send-pack</tt> on the other end, so you can simply <tt>echo</tt> messages\r
+for the user.</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 12-May-2007 20:49:27 UTC\r
+Last updated 13-May-2007 22:18:55 UTC\r
</div>\r
</div>\r
</body>\r
updated. If the hook exits with zero, updating of individual refs can
still be prevented by the <<update,'update'>> hook.
-If you want to report something to the `git-send-pack` on the other end,
-you can simply `echo` your messages.
+Both standard output and standard error output are forwarded to
+`git-send-pack` on the other end, so you can simply `echo` messages
+for the user.
[[update]]
update
implement access control which is finer grained than the one
based on filesystem group.
-The standard output of this hook is sent to `stderr`, so if you
-want to report something to the `git-send-pack` on the other end,
-you can simply `echo` your messages.
+Both standard output and standard error output are forwarded to
+`git-send-pack` on the other end, so you can simply `echo` messages
+for the user.
The default 'update' hook, when enabled--and with
`hooks.allowunannotated` config option turned on--prevents
been updated.
This hook executes once for the receive operation. It takes no
-arguments, but gets the same information as the `pre-receive`
+arguments, but gets the same information as the
+<<pre-receive,'pre-receive'>>
hook does on its standard input.
This hook does not affect the outcome of `git-receive-pack`, as it
is called after the real work is done.
-This supersedes the [[post-update]] hook in that it actually get's
-both old and new values of all the refs.
+This supersedes the <<post-update,'post-update'>> hook in that it get's
+both old and new values of all the refs in addition to their
+names.
-If you want to report something to the `git-send-pack` on the
-other end, you can simply `echo` your messages.
+Both standard output and standard error output are forwarded to
+`git-send-pack` on the other end, so you can simply `echo` messages
+for the user.
The default 'post-receive' hook is empty, but there is
a sample script `post-receive-email` provided in the `contrib/hooks`
The 'post-update' hook can tell what are the heads that were pushed,
but it does not know what their original and updated values are,
-so it is a poor place to do log old..new.
-
-In general, `post-receive` hook is preferred when the hook needs
-to decide its acion on the status of the entire set of refs
-being updated, as this hook is called once per ref, with
-information only on a single ref at a time.
+so it is a poor place to do log old..new. The
+<<post-receive,'post-receive'>> hook does get both original and
+updated values of the refs. You might consider it instead if you need
+them.
When enabled, the default 'post-update' hook runs
`git-update-server-info` to keep the information used by dumb
probably enable this hook.
Both standard output and standard error output are forwarded to
-`git-send-pack` on the other end.
+`git-send-pack` on the other end, so you can simply `echo` messages
+for the user.
$ git --bare update-server-info<br>
$ chmod a+x hooks/post-update</p></div><p>(For an explanation of the last two lines, see
<a href="git-update-server-info.html" target="_top">git-update-server-info(1)</a>, and the documentation
-<a href="hooks.
txt" target="_top">Hooks used by git</a>.)</p><p>Advertise the url of proj.git. Anybody else should then be able to
+<a href="hooks.
html" target="_top">Hooks used by git</a>.)</p><p>Advertise the url of proj.git. Anybody else should then be able to
clone or pull from that url, for example with a commandline like:</p><div class="literallayout"><p>$ git clone http://yourserver.com/~you/proj.git</p></div><p>(See also
<a href="howto/setup-git-server-over-http.txt" target="_top">setup-git-server-over-http</a>
for a slightly more sophisticated setup using WebDAV which also
details.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="setting-up-a-shared-repository"></a>Setting up a shared repository</h2></div></div></div><p>Another way to collaborate is by using a model similar to that
commonly used in CVS, where several developers with special rights
all push to and pull from a single shared repository. See
-<a href="cvs-migration.txt" target="_top">git for CVS users</a> for instructions on how to
+<a href="cvs-migration.html" target="_top">git for CVS users</a> for instructions on how to
set this up.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="setting-up-gitweb"></a>Allow web browsing of a repository</h2></div></div></div><p>The gitweb cgi script provides users an easy way to browse your
project's files and history without having to install git; see the file
gitweb/INSTALL in the git source tree for instructions on setting it up.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sharing-development-examples"></a>Examples</h2></div></div></div><p>TODO: topic branches, typical roles as in everyday.txt, ?</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="cleaning-up-history"></a>Chapter 6. Rewriting history and maintaining patch series</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#patch-series">Creating the perfect patch series</a></span></dt><dt><span class="section"><a href="#using-git-rebase">Keeping a patch series up to date using git-rebase</a></span></dt><dt><span class="section"><a href="#modifying-one-commit">Modifying a single commit</a></span></dt><dt><span class="section"><a href="#reordering-patch-series">Reordering or selecting from a patch series</a></span></dt><dt><span class="section"><a href="#patch-series-tools">Other tools</a></span></dt><dt><span class="section"><a href="#problems-with-rewriting-history">Problems with rewriting history</a></span></dt></dl></div><p>Normally commits are only added to a project, never taken away or
(For an explanation of the last two lines, see
gitlink:git-update-server-info[1], and the documentation
-link:hooks.txt[Hooks used by git].)
+link:hooks.html[Hooks used by git].)
Advertise the url of proj.git. Anybody else should then be able to
clone or pull from that url, for example with a commandline like:
Another way to collaborate is by using a model similar to that
commonly used in CVS, where several developers with special rights
all push to and pull from a single shared repository. See
-link:cvs-migration.txt[git for CVS users] for instructions on how to
+link:cvs-migration.html[git for CVS users] for instructions on how to
set this up.
[[setting-up-gitweb]]
projects / git.git / commitdiff