t3100: add ls-tree -t and -d tests.
[gitweb.git] / Documentation / git-archimport.txt
index 6054731741c6213e4e79c2ca117af10f6923e5b3..fcda0125af92ff9c3d72d711a78d23118787608c 100644 (file)
@@ -3,7 +3,7 @@ git-archimport(1)
 
 NAME
 ----
-git-archimport - Import an Arch repository into GIT
+git-archimport - Import an Arch repository into git
 
 
 SYNOPSIS
@@ -20,31 +20,34 @@ 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). 
 
 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. 
+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 import. 
+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. 
 
-`git-archimport` uses `tla` extensively in the background to access the Arch repository.
+`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`. 
 
 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.
+`git-archimport` with the same parameters as the initial import to perform 
+incremental imports.
 
 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