NAME
----
-git-archimport - Import an Arch repository into GIT
+git-archimport - Import an Arch repository into git
SYNOPSIS
--------
-`git-archimport` [ -h ] [ -v ] [ -T ] [ -t tempdir ]
- <archive/branch> [ <archive/branch> ]
+[verse]
+'git-archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
+ <archive/branch>[:<git-branch>] ...
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 suppplied. If it cannot find the remote branch a merge comes from
+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).
`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
+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
+is that git will have a good idea of how far branches have diverged. So the
import process does lose some patch-trading metadata.
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
+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.
OPTIONS
Many tags. Will create a tag for every commit, reflecting the commit
name in the Arch repository.
+-f::
+ 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.
+
+-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. 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
+ merged from. Specify a depth greater than 1 if patch logs have been
+ pruned.
+
+-a::
+ Attempt to auto-register archives at http://mirrors.sourcecontrol.net
+ This is particularly useful with the -D option.
+
-t <tmpdir>::
Override the default tempdir.