Git

名称

git-archimport - 将 GNU Arch 仓库导入 Git 中

概述

git archimport [-h] [-v] [-o] [-a] [-f] [-T] [-D <深度>] [-t <缓存目录>]
	       <归档>/<分支>[:<git 分支>]…​

描述

从一个或多个 GNU Arch 仓库导入一个项目。 它将在所提供的 <归档>/<分支> 参数所定义的命名空间内跟踪分支和仓库。如果它找不到合并后的远程分支，就会把它作为一个普通的提交导入。如果它能找到它，它会尽可能地将其标记为合并（见下面的讨论）。

该脚本希望你提供关键的根目录，它可以从 initial 或 tag 类型的 Arch 提交开始导入。它将跟踪并导入所提供的根目录下的新分支。

它希望只处理一个项目。如果它看到有不同根目录的分支，它将拒绝运行。在这种情况下，编辑你的 <归档>/<分支> 参数，以明确定义导入的范围。

git archimport 在后台广泛使用 tla 来访问 Arch 仓库。 确保你的路径中有一个最新版本的 tla。tla 必须知道你传递给 git archimport 的仓库。

对于初始导入，git archimport 希望能在一个空目录中找到自己。要跟踪一个使用 Arch 的项目的发展，重新运行 git archimport，参数与初始导入相同，以执行增量导入。

虽然 git archimport 会尝试为它导入的档案创建合理的分支名，但也可以手动指定 Git 分支名。 要做到这一点，在每个 <归档>/<分支> 参数后面写一个 Git 分支名，用冒号隔开。 这样，你可以缩短 Arch 分支的名称，并将 Arch 的行话转换成 Git 的行话，例如将 "PROJECT--devo--VERSION" 分支映射为 "master"。

将多个 Arch 分支关联到一个 Git 分支是可能的；只有在创建第二个分支后没有向第一个分支提交的情况下，其结果才是最合理的。 不过，这对于转换定期轮换的 Arch 仓库还是很有用的。

合并

Arch 的补丁合并数据在 Git 中也被用来标记合并。Git 并不关心对补丁的追踪，只有当一个分支包含了自分叉点以来的所有提交时，才会考虑合并。最终的结果是，Git 会很好地了解分支的分歧程度。所以导入过程确实会丢失一些补丁交易的元数据。

幸运的是，当你尝试合并从 Arch 导入的分支时，Git 会找到一个好的合并基础，而且它有很大的机会识别出在分支之间被交易的不符合顺序的补丁。

选项

-h

显示用途。

-v

详细输出。

-T

多标签。将为每个提交创建一个标签，反映 Arch 库中的提交名称。

-f

使用快速补丁集导入策略。 这对大目录树来说可以明显加快，但不能处理目录重名或权限变化。 默认策略是缓慢而安全的。

-o

为了与早期版本的 git archimport 所使用的旧式分支名兼容，使用这个名字。 旧式的分支名是 category--branch，而新式的分支名是 archive,category--branch--version。 在这两种情况下，在命令行中给出的名字将覆盖自动生成的名字。

-D <深度>

遵循合并的祖先，并尝试导入已经合并的目录树。 如果补丁日志已经被修剪，则指定一个大于 1 的深度。

-a

尝试在 http://mirrors.sourcecontrol.net 上自动注册档案，这在 -D 选项下特别有用。

-t <缓存目录>

重写默认缓存目录。

<归档>/<分支>

<归档>/<分支> 标识符的格式是 tla log 能理解的。

GIT

属于 git[1] 文档

scroll-to-top