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
The script expects you to provide the key roots where it can start
the import from an initial import or tag type of Arch commit. It will
follow and import new branches within the provided roots.
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
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 gitarchimport.
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.
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
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
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.
Many tags. Will create a tag for every commit, reflecting the
commit name in the Arch repository.
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.
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.
Follow merge ancestry and attempt to import trees that have been
merged from. Specify a depth greater than 1 if patch logs have
Attempt to auto-register archives at
http://mirrors.sourcecontrol.net This is particularly useful with
the -D option.
Override the default tempdir.
Archive/branch identifier in a format that tla log understands.
This page is part of the git (Git distributed version control system)
project. Information about the project can be found at
⟨http://git-scm.com/⟩. If you have a bug report for this manual page,
see ⟨http://git-scm.com/community⟩. This page was obtained from the
project's upstream Git repository ⟨https://github.com/git/git.git⟩ on
2017-03-13. If you discover any rendering problems in this HTML ver‐
sion of the page, or you believe there is a better or more up-to-date
source for the page, or you have corrections or improvements to the
information in this COLOPHON (which is not part of the original man‐
ual page), send a mail to firstname.lastname@example.org
Git 2.7.0.rc1.5.gf3a 12/17/2015 GIT-ARCHIMPORT(1)