.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
-.TH "GIT\-ARCHIMPORT" "1" "10/03/2006" "" ""
+.TH "GIT\-ARCHIMPORT" "1" "03/08/2007" "" ""
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.sp
.nf
\fIgit\-archimport\fR [\-h] [\-v] [\-o] [\-a] [\-f] [\-T] [\-D depth] [\-t tempdir]
- <archive/branch> [ <archive/branch> ]
+ <archive/branch>[:<git\-branch>] \&...
.fi
.SH "DESCRIPTION"
Imports a project from one or more Arch repositories. It will follow branches and repositories within the namespaces defined by the <archive/branch> parameters supplied. If it cannot find the remote branch a merge comes from it will just import it as a regular commit. If it can find it, it will mark it as a merge whenever possible (see discussion below).
-.sp
+
The script expects you to provide the key roots where it can start the import from an \fIinitial import\fR or \fItag\fR type of Arch commit. It will follow and import new branches within the provided roots.
-.sp
+
It expects to be dealing with one project only. If it sees branches that have different roots, it will refuse to run. In that case, edit your <archive/branch> parameters to define clearly the scope of the import.
-.sp
+
git\-archimport uses tla extensively in the background to access the Arch repository. Make sure you have a recent version of tla available in the path. tla must know about the repositories you pass to git\-archimport.
-.sp
+
For the initial import git\-archimport expects to find itself in an empty 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.
-.sp
+
+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.
.SH "MERGES"
Patch merge data from Arch is used to mark merges in git as well. git does not care much about tracking patches, and only considers a merge when a branch incorporates all the commits since the point they forked. The end result is that git will have a good idea of how far branches have diverged. So the import process does lose some patch\-trading metadata.
-.sp
+
Fortunately, when you try and merge branches imported from Arch, git will find a good merge base, and it has a good chance of identifying patches that have been traded out\-of\-sequence between the branches.
-.sp
.SH "OPTIONS"
.TP
\-h
Use the fast patchset import strategy. This can be significantly faster for large trees, but cannot handle directory renames or permissions changes. The default strategy is slow and safe.
.TP
\-o
-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.
+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. In both cases, names given on the command\-line will override the automatically\-generated ones.
.TP
\-D <depth>
Follow merge ancestry and attempt to import trees that have been merged from. Specify a depth greater than 1 if patch logs have been pruned.
Override the default tempdir.
.TP
<archive/branch>
-Archive/branch identifier in a format that
-tla log
-understands.
+Archive/branch identifier in a format that tla log understands.
.SH "AUTHOR"
Written by Martin Langhoff <martin@catalyst.net.nz>.
-.sp
.SH "DOCUMENTATION"
Documentation by Junio C Hamano, Martin Langhoff and the git\-list <git@vger.kernel.org>.
-.sp
.SH "GIT"
Part of the \fBgit\fR(7) suite
-.sp
+
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
-.TH "GIT\-RECEIVE\-PACK" "1" "01/19/2007" "" ""
+.TH "GIT\-RECEIVE\-PACK" "1" "03/08/2007" "" ""
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
The command allows for creation and fast forwarding of sha1 refs (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?)
-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\-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.
+.SH "OPTIONS"
+.TP
+<directory>
+The repository to sync into.
+.SH "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:
+.sp
+.nf
+$GIT_DIR/hooks/pre\-receive (refname sha1\-old sha1\-new)+
+.fi
+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.
+.SH "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:
.sp
.nf
$GIT_DIR/hooks/update refname sha1\-old sha1\-new
.fi
-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 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.
-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:
+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.
+.SH "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:
+.sp
+.nf
+$GIT_DIR/hooks/post\-receive (refname sha1\-old sha1\-new)+
+.fi
+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:
.sp
.nf
#!/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
.fi
-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.
+.SH "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.
.sp
.nf
#!/bin/sh
exec git\-update\-server\-info
.fi
-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.
-.SH "OPTIONS"
-.TP
-<directory>
-The repository to sync into.
.SH "SEE ALSO"
\fBgit\-send\-pack\fR(1)
.SH "AUTHOR"
projects / git.git / commitdiff