From abcd65d67e1430fd2ac0634681a0bf1587c039b0 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Thu, 8 Mar 2007 02:43:00 +0000 Subject: [PATCH] Autogenerated HTML docs for v1.5.0.3-310-g05ef5 --- git-archimport.html | 18 ++++- git-archimport.txt | 19 +++++- git-receive-pack.html | 152 +++++++++++++++++++++++++++++------------- git-receive-pack.txt | 149 +++++++++++++++++++++++++++++------------ git.html | 2 +- 5 files changed, 245 insertions(+), 95 deletions(-) diff --git a/git-archimport.html b/git-archimport.html index 887acd215..9ecbb6349 100644 --- a/git-archimport.html +++ b/git-archimport.html @@ -274,7 +274,7 @@ git-archimport(1) Manual Page
git-archimport [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir] - <archive/branch> [ <archive/branch> ]
+ <archive/branch>[:<git-branch>] …

DESCRIPTION

@@ -298,6 +298,16 @@ know about the repositories you pass to git-archimport.

directory. To follow the development of a project that uses Arch, rerun git-archimport with the same parameters as the initial import to perform incremental imports.

+

While git-archimport will try to create sensible branch names for the +archives that it imports, it is also possible to specify git branch names +manually. To do so, write a git branch name after each <archive/branch> +parameter, separated by a colon. This way, you can shorten the Arch +branch names and convert Arch jargon to git jargon, for example mapping a +"PROJECT--devo--VERSION" branch to "master".

+

Associating multiple Arch branches to one git branch is possible; the +result will make the most sense only if no commits are made to the first +branch, after the second branch is created. Still, this is useful to +convert Arch repositories that had been rotated periodically.

MERGES

@@ -356,7 +366,9 @@ patches that have been traded out-of-sequence between the branches.

Use this for compatibility with old-style branch names used by earlier versions of git-archimport. Old-style branch names were category--branch, whereas new-style branch names are - archive,category--branch--version. + archive,category--branch--version. In both cases, names given + on the command-line will override the automatically-generated + ones.

@@ -410,7 +422,7 @@ patches that have been traded out-of-sequence between the branches.

diff --git a/git-archimport.txt b/git-archimport.txt index 5a13187a8..82cb41d27 100644 --- a/git-archimport.txt +++ b/git-archimport.txt @@ -10,7 +10,7 @@ SYNOPSIS -------- [verse] 'git-archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir] - [ ] + [:] ... DESCRIPTION ----------- @@ -39,6 +39,19 @@ directory. To follow the development of a project that uses Arch, rerun `git-archimport` with the same parameters as the initial import to perform incremental imports. +While git-archimport will try to create sensible branch names for the +archives that it imports, it is also possible to specify git branch names +manually. To do so, write a git branch name after each +parameter, separated by a colon. This way, you can shorten the Arch +branch names and convert Arch jargon to git jargon, for example mapping a +"PROJECT--devo--VERSION" branch to "master". + +Associating multiple Arch branches to one git branch is possible; the +result will make the most sense only if no commits are made to the first +branch, after the second branch is created. Still, this is useful to +convert Arch repositories that had been rotated periodically. + + MERGES ------ Patch merge data from Arch is used to mark merges in git as well. git @@ -73,7 +86,9 @@ OPTIONS Use this for compatibility with old-style branch names used by earlier versions of git-archimport. Old-style branch names were category--branch, whereas new-style branch names are - archive,category--branch--version. + archive,category--branch--version. In both cases, names given + on the command-line will override the automatically-generated + ones. -D :: Follow merge ancestry and attempt to import trees that have been 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 git-fetch-pack.

(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?)

+

There are other real-world examples of using update and +post-update hooks found in the Documentation/howto directory.

+

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.

+ +

OPTIONS

+
+
+
+<directory> +
+
+

+ The repository to sync into. +

+
+
+
+

pre-receive Hook

+
+

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:

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

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.

+

This hook is called before any refname is updated and before any +fast-forward checks are performed.

+

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.

+
+

update Hook

+

Before each ref is updated, if $GIT_DIR/hooks/update file exists -and executable, it is called with three parameters:

+and is executable, it is invoked once per ref, with three parameters:

$GIT_DIR/hooks/update refname sha1-old sha1-new
-

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.

-

The hook should exit with non-zero status if it wants to -disallow updating the named ref. Otherwise it should exit with -zero.

-

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:

+

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.

+

The hook should exit with non-zero status if it wants to disallow +updating the named ref. Otherwise it should exit with zero.

+

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.

+
+

post-receive Hook

+
+

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:

+
+
+
$GIT_DIR/hooks/post-receive (refname sha1-old sha1-new)+
+
+

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.

+

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:

#!/bin/sh
 # mail out commit update information.
-if expr "$2" : '0*$' >/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*$' >/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
-

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.

+

The exit code from this hook invocation is ignored, however a +non-zero exit code will generate an error message.

+

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.

+
+

post-update Hook

+
+

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.

+

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.

#!/bin/sh
 exec git-update-server-info
-

There are other real-world examples of using update and -post-update hooks found in the Documentation/howto directory.

-

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.

-
-

OPTIONS

-
-
-
-<directory> -
-
-

- The repository to sync into. -

-
-

SEE ALSO

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

diff --git a/git-receive-pack.txt b/git-receive-pack.txt index 10e8c46c4..3cf55111c 100644 --- a/git-receive-pack.txt +++ b/git-receive-pack.txt @@ -25,61 +25,126 @@ The command allows for creation and fast forwarding of sha1 refs local end receive-pack runs, but to the user who is sitting at the send-pack end, it is updating the remote. Confused?) -Before each ref is updated, if $GIT_DIR/hooks/update file exists -and executable, it is called with three parameters: +There are other real-world examples of using update and +post-update hooks found in the Documentation/howto directory. - $GIT_DIR/hooks/update refname sha1-old sha1-new +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. + +OPTIONS +------- +:: + The repository to sync into. + +pre-receive Hook +---------------- +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: + + $GIT_DIR/hooks/pre-receive (refname sha1-old sha1-new)+ + +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 to be created will have sha1-old equal to 0{40}, +while refs to be deleted will have sha1-new equal to 0{40}, otherwise +sha1-old and sha1-new should be valid objects in the repository. + +This hook is called before any refname is updated and before any +fast-forward checks are performed. + +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. -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 -sha1-old is 0{40} (meaning there is no such ref yet), or it -should match what is recorded in refname. +update Hook +----------- +Before each ref is updated, if $GIT_DIR/hooks/update file exists +and is executable, it is invoked once per ref, with three parameters: -The hook should exit with non-zero status if it wants to -disallow updating the named ref. Otherwise it should exit with -zero. + $GIT_DIR/hooks/update refname sha1-old sha1-new -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: +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, +so either sha1-old is 0{40} (meaning there is no such ref yet), +or it should match what is recorded in refname. + +The hook should exit with non-zero status if it wants to disallow +updating the named ref. Otherwise it should exit with zero. + +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. + +post-receive Hook +----------------- +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: + + $GIT_DIR/hooks/post-receive (refname sha1-old sha1-new)+ + +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 +0{40}, while refs that were deleted will have sha1-new equal to +0{40}, otherwise sha1-old and sha1-new should be valid objects in +the repository. + +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: #!/bin/sh # mail out commit update information. - if expr "$2" : '0*$' >/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*$' >/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 -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. +The exit code from this hook invocation is ignored, however a +non-zero exit code will generate an error message. - #!/bin/sh - exec git-update-server-info +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. -There are other real-world examples of using update and -post-update hooks found in the Documentation/howto directory. +post-update Hook +---------------- +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. -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. +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. -OPTIONS -------- -:: - The repository to sync into. +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. + + #!/bin/sh + exec git-update-server-info SEE ALSO diff --git a/git.html b/git.html index 723423042..9824b5183 100644 --- a/git.html +++ b/git.html @@ -2309,7 +2309,7 @@ contributors on the git-list <git@vger.kernel.org>.

-- 2.26.2