<div class="sectionbody">\r
<div class="verseblock">\r
<div class="content"><em>git-archimport</em> [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]\r
- <archive/branch> [ <archive/branch> ]</div></div>\r
+ <archive/branch>[:<git-branch>] …</div></div>\r
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
directory. To follow the development of a project that uses Arch, rerun\r
<tt>git-archimport</tt> with the same parameters as the initial import to perform\r
incremental imports.</p>\r
+<p>While git-archimport will try to create sensible branch names for the\r
+archives that it imports, it is also possible to specify git branch names\r
+manually. To do so, write a git branch name after each <archive/branch>\r
+parameter, separated by a colon. This way, you can shorten the Arch\r
+branch names and convert Arch jargon to git jargon, for example mapping a\r
+"PROJECT--devo--VERSION" branch to "master".</p>\r
+<p>Associating multiple Arch branches to one git branch is possible; the\r
+result will make the most sense only if no commits are made to the first\r
+branch, after the second branch is created. Still, this is useful to\r
+convert Arch repositories that had been rotated periodically.</p>\r
</div>\r
<h2>MERGES</h2>\r
<div class="sectionbody">\r
Use this for compatibility with old-style branch names used by\r
earlier versions of git-archimport. Old-style branch names\r
were category--branch, whereas new-style branch names are\r
- archive,category--branch--version.\r
+ archive,category--branch--version. In both cases, names given\r
+ on the command-line will override the automatically-generated\r
+ ones.\r
</p>\r
</dd>\r
<dt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 03-Oct-2006 08:40:52 UTC\r
+Last updated 08-Mar-2007 02:42:38 UTC\r
</div>\r
</div>\r
</body>\r
--------
[verse]
'git-archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
- <archive/branch> [ <archive/branch> ]
+ <archive/branch>[:<git-branch>] ...
DESCRIPTION
-----------
`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
------
Patch merge data from Arch is used to mark merges in git as well. git
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 <depth>::
Follow merge ancestry and attempt to import trees that have been
(heads/tags) on the remote end (strictly speaking, it is the\r
local end receive-pack runs, but to the user who is sitting at\r
the send-pack end, it is updating the remote. Confused?)</p>\r
+<p>There are other real-world examples of using update and\r
+post-update hooks found in the Documentation/howto directory.</p>\r
+<p>git-receive-pack honours the receive.denyNonFastForwards config\r
+option, which tells it if updates to a ref should be denied if they\r
+are not fast-forwards.</p>\r
+</div>\r
+<h2>OPTIONS</h2>\r
+<div class="sectionbody">\r
+<dl>\r
+<dt>\r
+<directory>\r
+</dt>\r
+<dd>\r
+<p>\r
+ The repository to sync into.\r
+</p>\r
+</dd>\r
+</dl>\r
+</div>\r
+<h2>pre-receive Hook</h2>\r
+<div class="sectionbody">\r
+<p>Before any ref is updated, if $GIT_DIR/hooks/pre-receive file exists\r
+and is executable, it will be invoked once, with three parameters\r
+per ref to be updated:</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>$GIT_DIR/hooks/pre-receive (refname sha1-old sha1-new)+</tt></pre>\r
+</div></div>\r
+<p>The refname parameter is relative to $GIT_DIR; e.g. for the master\r
+head this is "refs/heads/master". The two sha1 arguments after\r
+each refname are the object names for the refname before and after\r
+sha1-old and sha1-new should be valid objects in the repository.</p>\r
+<p>This hook is called before any refname is updated and before any\r
+fast-forward checks are performed.</p>\r
+<p>If the pre-receive hook exits with a non-zero exit status no updates\r
+will be performed, and the update, post-receive and post-update\r
+hooks will not be invoked either. This can be useful to quickly\r
+bail out if the update is not to be supported.</p>\r
+</div>\r
+<h2>update Hook</h2>\r
+<div class="sectionbody">\r
<p>Before each ref is updated, if $GIT_DIR/hooks/update file exists\r
-and executable, it is called with three parameters:</p>\r
+and is executable, it is invoked once per ref, with three parameters:</p>\r
<div class="literalblock">\r
<div class="content">\r
<pre><tt>$GIT_DIR/hooks/update refname sha1-old sha1-new</tt></pre>\r
</div></div>\r
-<p>The refname parameter is relative to $GIT_DIR; e.g. for the\r
-master head this is "refs/heads/master". Two sha1 are the\r
-object names for the refname before and after the update. Note\r
-that the hook is called before the refname is updated, so either\r
-should match what is recorded in refname.</p>\r
-<p>The hook should exit with non-zero status if it wants to\r
-disallow updating the named ref. Otherwise it should exit with\r
-zero.</p>\r
-<p>Using this hook, it is easy to generate mails on updates to\r
-the local repository. This example script sends a mail with\r
-the commits pushed to the repository:</p>\r
+<p>The refname parameter is relative to $GIT_DIR; e.g. for the master\r
+head this is "refs/heads/master". The two sha1 arguments are\r
+the object names for the refname before and after the update.\r
+Note that the hook is called before the refname is updated,\r
+or it should match what is recorded in refname.</p>\r
+<p>The hook should exit with non-zero status if it wants to disallow\r
+updating the named ref. Otherwise it should exit with zero.</p>\r
+<p>Successful execution (a zero exit status) of this hook does not\r
+ensure the ref will actully be updated, it is only a prerequisite.\r
+As such it is not a good idea to send notices (e.g. email) from\r
+this hook. Consider using the post-receive hook instead.</p>\r
+</div>\r
+<h2>post-receive Hook</h2>\r
+<div class="sectionbody">\r
+<p>After all refs were updated (or attempted to be updated), if any\r
+ref update was successful, and if $GIT_DIR/hooks/post-receive\r
+file exists and is executable, it will be invoke once with three\r
+parameters for each successfully updated ref:</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>$GIT_DIR/hooks/post-receive (refname sha1-old sha1-new)+</tt></pre>\r
+</div></div>\r
+<p>The refname parameter is relative to $GIT_DIR; e.g. for the master\r
+head this is "refs/heads/master". The two sha1 arguments after\r
+each refname are the object names for the refname before and after\r
+the update. Refs that were created will have sha1-old equal to\r
+the repository.</p>\r
+<p>Using this hook, it is easy to generate mails describing the updates\r
+to the repository. This example script sends one mail message per\r
+ref listing the commits pushed to the repository:</p>\r
<div class="literalblock">\r
<div class="content">\r
<pre><tt>#!/bin/sh\r
# mail out commit update information.\r
-if expr "$2" : '0*$' >/dev/null\r
-then\r
- echo "Created a new ref, with the following commits:"\r
- git-rev-list --pretty "$2"\r
-else\r
- echo "New commits:"\r
- git-rev-list --pretty "$3" "^$2"\r
-fi |\r
-mail -s "Changes to ref $1" commit-list@mydomain\r
+while test $# -gt 0\r
+do\r
+ if expr "$2" : '0*$' >/dev/null\r
+ then\r
+ echo "Created a new ref, with the following commits:"\r
+ git-rev-list --pretty "$2"\r
+ else\r
+ echo "New commits:"\r
+ git-rev-list --pretty "$3" "^$2"\r
+ fi |\r
+ mail -s "Changes to ref $1" commit-list@mydomain\r
+ shift; shift; shift; # discard this ref's args\r
+done\r
exit 0</tt></pre>\r
</div></div>\r
-<p>Another hook $GIT_DIR/hooks/post-update, if exists and\r
-executable, is called with the list of refs that have been\r
-updated. This can be used to implement repository wide cleanup\r
-task if needed. The exit code from this hook invocation is\r
-ignored; the only thing left for git-receive-pack to do at that\r
-point is to exit itself anyway. This hook can be used, for\r
-example, to run "git-update-server-info" if the repository is\r
-packed and is served via a dumb transport.</p>\r
+<p>The exit code from this hook invocation is ignored, however a\r
+non-zero exit code will generate an error message.</p>\r
+<p>Note that it is possible for refname to not have sha1-new when this\r
+hook runs. This can easily occur if another user modifies the ref\r
+after it was updated by receive-pack, but before the hook was able\r
+to evaluate it. It is recommended that hooks rely on sha1-new\r
+rather than the current value of refname.</p>\r
+</div>\r
+<h2>post-update Hook</h2>\r
+<div class="sectionbody">\r
+<p>After all other processing, if at least one ref was updated, and\r
+if $GIT_DIR/hooks/post-update file exists and is executable, then\r
+post-update will called with the list of refs that have been updated.\r
+This can be used to implement any repository wide cleanup tasks.</p>\r
+<p>The exit code from this hook invocation is ignored; the only thing\r
+left for git-receive-pack to do at that point is to exit itself\r
+anyway.</p>\r
+<p>This hook can be used, for example, to run "git-update-server-info"\r
+if the repository is packed and is served via a dumb transport.</p>\r
<div class="literalblock">\r
<div class="content">\r
<pre><tt>#!/bin/sh\r
exec git-update-server-info</tt></pre>\r
</div></div>\r
-<p>There are other real-world examples of using update and\r
-post-update hooks found in the Documentation/howto directory.</p>\r
-<p>git-receive-pack honours the receive.denyNonFastforwards flag, which\r
-tells it if updates to a ref should be denied if they are not fast-forwards.</p>\r
-</div>\r
-<h2>OPTIONS</h2>\r
-<div class="sectionbody">\r
-<dl>\r
-<dt>\r
-<directory>\r
-</dt>\r
-<dd>\r
-<p>\r
- The repository to sync into.\r
-</p>\r
-</dd>\r
-</dl>\r
</div>\r
<h2>SEE ALSO</h2>\r
<div class="sectionbody">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jan-2007 00:37:30 UTC\r
+Last updated 08-Mar-2007 02:42:38 UTC\r
</div>\r
</div>\r
</body>\r
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
+-------
+<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
+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
--------
-<directory>::
- 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
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 06-Mar-2007 09:58:13 UTC\r
+Last updated 08-Mar-2007 02:42:39 UTC\r
</div>\r
</div>\r
</body>\r
projects / git.git / commitdiff