Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.39.1 → 2.43.0 no changes
- 2.39.0 12/12/22
- 2.28.1 → 2.38.5 no changes
- 2.28.0 07/27/20
描述
该程序会将给定的修订转储为适合导入 git fast-import 的形式。
你可以把它用作人类可读的 bundle 替换(参见 git-bundle[1]),也可以把它用作一种格式,在输入到 git fast-import 之前进行编辑,以便进行历史重写(git filter-repo 等工具依赖这种能力)。
选项
- --progress=<n>
-
每隔 <n> 个对象插入 progress (进度)语句,在导入时由 git fast-import 显示。
- --signed-tags=(verbatim|warn|warn-strip|strip|abort)
-
指定如何处理已签名的标记。 由于导出后的任何转换都可能更改标记名(排除修订时也可能发生这种情况),因此签名将不匹配。
当要求 abort(禁止,默认值)时,该程序将在遇到已签名标记时死亡。 如果使用 strip(剥夺),标签将被静默地取消签名;如果使用 warn-strip,标签将被取消签名,但会显示警告;如果使用 verbatim(逐字报告),标签将被静默地导出;如果使用 warn,标签将被导出,但会显示警告。
- --tag-of-filtered-object=(abort|drop|rewrite)
-
指定如何处理已过滤掉标记对象的标记。 由于要导出的版本和文件可能受路径限制,标记对象可能会被完全过滤掉。
如果要求 abort(终止,默认值),程序将在遇到此类标记时死亡。 如果使用 drop(丢弃),则会从输出中省略此类标记。 如果使用 rewrite(重写),如果标记对象是一个提交,程序将重写该标记以标记一个祖先提交(通过父级重写;参见 git-rev-list[1])
- -M
- -C
-
如 git-diff[1] 手册页所述,执行移动和/或复制检测,并在输出转储中生成重命名和复制命令。
请注意,如果您提供了这些选项,该命令的早期版本不会发出错误提示,并会产生不正确的结果。
- --export-marks=<file>
-
完成后将内部标记表转存到 <文件> 中。 标记以
:markid SHA-1
的形式每行写一个。只转储修订版的标记;忽略 blob 的标记。 后端可以在导入完成后使用此文件验证导入,或在增量运行时保存标记表。 由于 <文件> 仅在导入完成时打开并截断,因此也可以安全地为 --import-marks 提供相同的路径。 如果没有标记/导出新对象,文件将不会被写入。 - --import-marks=<file>
-
在处理任何输入之前,加载 <文件> 中指定的标记。 输入文件必须存在,必须可读,必须使用与 --export-marks 生成的相同格式。
- --mark-tags
-
除了用标记 id 标记 blob 和提交,还可以标记标签。 这与
--export-marks
(导出标记) 和--import-marks
(导入标记)`配合使用,对于导出嵌套标记也很有用(而且很必要)。 这对其他情况没有影响,也是默认做法,但许多快速导入前端并不准备接受带有标记标识符的标签。任何已标记的提交(或标记)都不会再次导出。 如果后端使用类似的 --import-marks 文件,则可以通过在不同运行中保持相同的标记来实现仓库的增量双向导出。
- --fake-missing-tagger
-
有些旧仓库有标签,但没有标记。 快速导入协议对此非常严格,不允许这样做。 所以要伪造一个标签,以便能够快速导入输出。
- --use-done-feature
-
用 feature done 字符串启动数据流,用 done 命令终止数据流。
- --no-data
-
跳过 blob 对象的输出,而是通过其原始 SHA-1 哈希值引用 blob。 这在重写仓库的目录结构或历史记录时非常有用,而且不会触及单个文件的内容。 请注意,生成的数据流只能由已包含必要对象的仓库使用。
- --full-tree
-
该选项将导致 fast-export 为每个提交发出一个 "deleteall" 指令,然后列出提交中所有文件的完整列表(而不是只列出与提交的第一个父文件不同的文件)。
- --anonymize
-
对资源库的内容进行匿名化处理,同时仍保留历史记录和存储树的形状。 请参阅下文
匿名化
部分。 - --anonymize-map=<from>[:<to>]
-
将匿名化输出中的令牌
<from>
转换为<to>
。如果省略了<to>
,则将<from>
映射到其本身(即不对其进行匿名化)。请参阅下面的匿名化
部分。 - --reference-excluded-parents
-
默认情况下,运行诸如
git fast-export master~5..master
这样的命令不会包含 master~5 提交,并会使 master~4 不再将 master~5 作为父提交(尽管旧的 master~4 和新的 master~4 拥有相同的文件)。 使用 --reference-excluded-parents 可以让数据流通过 sha1sum 来引用历史中排除范围内的提交。 需要注意的是,生成的数据流只能由已包含必要父提交的仓库使用。 - --show-original-ids
-
为提交和 blob 的输出添加一个额外的指令:
original-oid <SHA1SUM>
。 虽然这类指令可能会被 git-fast-import 等导入程序忽略,但对于中间过滤器(例如重写引用较早提交的提交信息,或按 id 剔除 blobs)来说可能很有用。 - --reencode=(yes|no|abort)
-
指定如何处理提交对象中的
encoding
(编码)头。 如果要求 abort(中止,默认值),程序将在遇到此类提交对象时结束。 如果使用 yes,提交信息将被重新编码为 UTF-8。 如果选择 no,则将保留原始编码。 - --refspec
-
对导出的每个引用应用指定的引用规范。可以指定多个。
- [<git-rev-list-args>…]
-
git rev-parse 和 git rev-list 可接受的参数列表,用于指定要导出的特定对象和引用。 例如,
master~10..master
会导出当前的主引用,以及其第 10 次祖先提交后添加的所有对象,以及(除非指定了 --reference-excluded-parents 选项)master~9 和 master~10 的所有公共文件。
实例
$ git fast-export --all | (cd /empty/repository && git fast-import)
这将导出整个仓库,并导入现有的空仓库。 除了对非 UTF-8 版本的提交进行重新编码外,这将是一个一对一的镜像。
$ git fast-export master~5..master | sed "s|refs/heads/master|refs/heads/other|" | git fast-import
这样就从 master~5..master 中创建了一个名为 other 的新分支(也就是说,如果 master 的历史是线性的,那么它将采用最近的 5 次提交)。
请注意,这是在假设该修订范围引用的 blob 和提交信息中没有包含 refs/heads/master 字符串。
匿名化
如果给定了 --anonymize
选项,git 会尝试移除仓库中的所有身份信息,但仍会保留足够的原始树和历史模式来重现某些 bug。这样做的目的是,在私有仓库中发现的 git bug 会在匿名仓库中继续存在,而后者可以与 git 开发人员共享,以帮助解决 bug。
使用该选项后,git 会用匿名数据替换输出中的所有引用名、路径、blob 内容、提交和标记信息、姓名和电子邮件地址。 同一字符串的两个实例将被等效替换(例如,两个提交的作者相同,输出中的匿名作者也相同,但与原始作者字符串并无相似之处)。提交、分支和标签之间的关系以及提交时间戳都会保留(但提交信息和引用名与原始信息没有任何相似之处)。保留树的相对构成(例如,如果根树有 10 个文件和 3 个树,输出也会保留),但文件名和文件内容会被替换。
如果您认为自己发现了一个 git bug,可以从导出整个仓库的匿名流开始:
$ git fast-export --anonymize --all >anon-stream
然后确认错误是否持续存在于根据该数据流创建的仓库中(许多错误不会持续存在,因为它们确实取决于仓库的确切内容):
$ git init anon-repo $ cd anon-repo $ git fast-import <../anon-stream $ ... test your bug ...
如果匿名仓库显示了错误,则值得在提交常规错误报告的同时分享 anon-stream
(匿名流)。请注意,匿名流的压缩效果非常好,因此建议将其压缩为 gzip 格式。如果您想检查流是否包含任何私人数据,可以在发送前直接阅读。您还可以尝试:
$ perl -pe 's/\d+/X/g' <anon-stream | sort -u | less
显示所有的唯一行(数字转换为 "X",将 "用户 0"、"用户 1" 等折叠为 "用户 X")。这样产生的输出要小得多,而且通常很容易快速确认数据流中没有私人数据。
重现某些错误可能需要引用特定的提交或路径,这在引用名和路径被匿名化后变得很有难度。您可以要求将特定标记保持原样或映射到一个新值。例如,如果有一个 bug 可以用 git rev-list sensitive -- secret.c
来重现,可以运行:
$ git fast-export --anonymize --all \ --anonymize-map=sensitive:foo \ --anonymize-map=secret.c:bar.c \ >stream
导入流之后,就可以在匿名仓库中运行 git rev-list foo -- bar.c
。
请注意,路径和引用名会在斜线边界被分割成标记。 上面的命令会将 subdir/secret.c
匿名化为类似 path123/bar.c
的内容;然后你可以在匿名化的仓库中搜索 bar.c
以确定最终路径名。
为了简化最终路径名的引用,可以对每个路径组件进行映射;因此,如果同时将 subdir
匿名化为 publicdir
,那么最终路径名将是 publicdir/bar.c
。
GIT
属于 git[1] 文档