From: Junio C Hamano Date: Sun, 13 May 2007 22:19:53 +0000 (+0000) Subject: Autogenerated HTML docs for v1.5.2-rc3-27-g43d151 X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=323e52dd2e49bceead5c67a881e8dc79db63e52c;p=git.git Autogenerated HTML docs for v1.5.2-rc3-27-g43d151 --- diff --git a/hooks.html b/hooks.html index 9a6616dff..9ddbedd74 100644 --- a/hooks.html +++ b/hooks.html @@ -358,8 +358,9 @@ When creating a new ref, <old-value> is 40 0.

If the hook exits with non-zero status, none of the refs will be updated. If the hook exits with zero, updating of individual refs can still be prevented by the 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

@@ -401,9 +402,9 @@ firing one e-mail per ref when used naively, though. The

Another use suggested on the mailing list is to use this hook to 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 unannotated tags to be pushed.

@@ -415,14 +416,17 @@ which happens when a git push is done on a local repository. It executes on the remote repository once after all the refs have 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 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 hook in that it actually get's -both old and new values of all the refs.

-

If you want to report something to the git-send-pack on the -other end, you can simply echo your messages.

+

This supersedes the post-update hook in that it get's +both old and new values of all the refs in addition to their +names.

+

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 directory in git distribution, which implements sending commit @@ -440,22 +444,22 @@ name of ref that was actually updated.

the outcome of git-receive-pack.

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 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 transports (e.g., HTTP) up-to-date. If you are publishing a git repository that is accessible via HTTP, you should 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.

diff --git a/hooks.txt b/hooks.txt index 80ba6709a..aabb9750f 100644 --- a/hooks.txt +++ b/hooks.txt @@ -115,8 +115,9 @@ If the hook exits with non-zero status, none of the refs will be updated. If the hook exits with zero, updating of individual refs can still be prevented by the <> 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 @@ -153,9 +154,9 @@ Another use suggested on the mailing list is to use this hook to 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 @@ -171,17 +172,20 @@ It executes on the remote repository once after all the refs have 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 +<> 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 <> 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` @@ -205,12 +209,10 @@ the outcome of `git-receive-pack`. 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 +<> 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 @@ -219,4 +221,5 @@ a git repository that is accessible via HTTP, you should 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. diff --git a/user-manual.html b/user-manual.html index 7bcf89c60..3f672cf41 100644 --- a/user-manual.html +++ b/user-manual.html @@ -721,7 +721,7 @@ $ $ git --bare update-server-info
$ chmod a+x hooks/post-update

(For an explanation of the last two lines, see git-update-server-info(1), and the documentation -Hooks used by git.)

Advertise the url of proj.git. Anybody else should then be able to +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:

$ git clone http://yourserver.com/~you/proj.git

(See also setup-git-server-over-http for a slightly more sophisticated setup using WebDAV which also @@ -745,7 +745,7 @@ and remote.<name>.push options in details.

Setting up a shared repository

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 -git for CVS users for instructions on how to +git for CVS users for instructions on how to set this up.

Allow web browsing of a repository

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.

Examples

TODO: topic branches, typical roles as in everyday.txt, ?

Chapter 6. Rewriting history and maintaining patch series

Table of Contents

Creating the perfect patch series
Keeping a patch series up to date using git-rebase
Modifying a single commit
Reordering or selecting from a patch series
Other tools
Problems with rewriting history

Normally commits are only added to a project, never taken away or diff --git a/user-manual.txt b/user-manual.txt index 13db9699c..a7abeaa1d 100644 --- a/user-manual.txt +++ b/user-manual.txt @@ -1875,7 +1875,7 @@ $ chmod a+x hooks/post-update (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: @@ -1959,7 +1959,7 @@ Setting up a shared repository 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]]