设置和配置
获取和创建项目
基本快照
分支与合并
共享和更新项目
检查和比较
打补丁
调试
电子邮件
外部系统
服务器管理
- 2.50.1 无更改
-
2.50.0
2025-06-16
- 2.45.1 → 2.49.1 无更改
-
2.45.0
2024-04-29
- 2.39.1 → 2.44.4 无更改
-
2.39.0
2022-12-12
- 2.28.1 → 2.38.5 无更改
-
2.28.0
2020-07-27
- 2.25.1 → 2.27.1 无变化
-
2.25.0
2020-01-13
- 2.24.1 → 2.24.4 无更改
-
2.24.0
2019-11-04
- 2.23.1 → 2.23.4 无更改
-
2.23.0
2019-08-16
- 2.21.1 → 2.22.5 无变更
-
2.21.0
2019-02-24
- 2.18.1 → 2.20.5 无更改
-
2.18.0
2018-06-21
- 2.5.6 → 2.17.6 无更改
-
2.4.12
2017-05-05
- 2.3.10 无更改
-
2.2.3
2015-09-04
-
2.1.4
2014-12-17
-
2.0.5
2014-12-17
描述
此程序以适合通过管道输入 git fast-import 的形式转储给定修订版本。
您可以将其用作人类可读的 bundle 替代品(参见 git-bundle[1]),或者用作在输入 git fast-import 之前可编辑的格式,以便进行历史重写(git filter-repo 等工具依赖此功能)。
选项
- --progress=<n>
-
每 <n> 个对象插入 progress 语句,以便在导入时由 git fast-import 显示。
- --signed-tags=(verbatim|warn-verbatim|warn-strip|strip|abort)
-
指定如何处理签名标签。由于导出后(或导出期间,例如排除修订版本)的任何转换都可能更改正在签名的哈希值,因此签名可能会失效。
当请求 abort(这是默认值)时,此程序在遇到签名标签时将终止。使用 strip 时,标签将静默地变为未签名;使用 warn-strip 时,标签将变为未签名但会显示警告;使用 verbatim 时,标签将静默导出;使用 warn-verbatim(或已弃用的同义词 warn)时,标签将导出,但会看到警告。verbatim 和 warn-verbatim 仅应在您知道不会由您或 fast-export 或 fast-import 执行影响标签或其历史记录中任何提交的转换,或者如果您不关心生成的标签将具有无效签名的情况下使用。
- --signed-commits=(verbatim|warn-verbatim|warn-strip|strip|abort)
-
指定如何处理签名提交。行为与 --signed-tags 完全相同,但适用于提交。默认值为 strip,这与此命令早期版本在没有此选项时的行为相同。
注意这是一个高度实验性的功能,数据流的格式将来可能会更改,不提供兼容性保证。 - --tag-of-filtered-object=(abort|drop|rewrite)
-
指定如何处理其标记对象被过滤掉的标签。由于要导出的修订版本和文件可以通过路径限制,因此标记对象可能会被完全过滤掉。
当请求 abort(这是默认值)时,此程序在遇到此类标签时将终止。使用 drop 时,它将从输出中省略此类标签。使用 rewrite 时,如果标记对象是提交,它将重写标签以标记祖先提交(通过父级重写;参见 git-rev-list[1])。
- -M
- -C
-
执行移动和/或复制检测,如 git-diff[1] 手册页中所述,并使用它在输出转储中生成重命名和复制命令。
请注意,此命令的早期版本在您给出这些选项时不会报错,但会产生不正确的结果。
- --export-marks=<file>
-
完成后将内部标记表转储到 <file>。标记以
:markid
SHA-1
的形式每行写入一个。只转储修订版本的标记;忽略 blob 的标记。后端可以使用此文件在导入完成后验证导入,或在增量运行中保存标记表。由于 <file> 只在完成时打开和截断,因此相同的路径也可以安全地提供给 --import-marks。如果没有新的对象被标记/导出,则不会写入此文件。 - --import-marks=<file>
-
在处理任何输入之前,加载 <file> 中指定的标记。输入文件必须存在、可读,并且必须使用与 --export-marks 生成的格式相同的格式。
- --mark-tags
-
除了使用标记 ID 标记 blob 和提交之外,还标记标签。这与
--export-marks
和--import-marks
结合使用非常有用,对于导出嵌套标签也很有用(且必要)。它不会损害其他情况,并且将是默认行为,但许多 fast-import 前端尚未准备好接受带有标记标识符的标签。任何已标记的提交(或标签)将不会再次导出。如果后端使用类似的 --import-marks 文件,则这允许通过在多次运行中保持标记相同来实现存储库的增量双向导出。
- --fake-missing-tagger
-
一些旧的存储库中存在没有标记者的标签。fast-import 协议对此非常严格,不允许这种情况。因此,伪造一个标记者以能够 fast-import 输出。
- --use-done-feature
-
以 feature done 节开始流,并以 done 命令结束。
- --no-data
-
跳过 blob 对象的输出,而是通过其原始 SHA-1 哈希引用 blob。这在重写存储库的目录结构或历史而不触及单个文件内容时很有用。请注意,生成的流只能由已包含必要对象的存储库使用。
- --full-tree
-
此选项将使 fast-export 为每个提交发出一个“deleteall”指令,后跟提交中所有文件的完整列表(而不是仅仅列出与提交的第一个父级不同的文件)。
- --anonymize
-
匿名化存储库的内容,同时保留历史和存储树的结构。请参阅下面的
ANONYMIZING
部分。 - --anonymize-map=<from>[:<to>]
-
在匿名化输出中将令牌 <from> 转换为 <to>。如果省略 <to>,则将 <from> 映射到自身(即,不进行匿名化)。请参阅下面的
ANONYMIZING
部分。 - --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 剥离 blob)。 - --reencode=(yes|no|abort)
-
指定如何处理提交对象中的
encoding
头。当请求 *abort*(这是默认值)时,此程序在遇到此类提交对象时将终止。使用 *yes* 时,提交消息将被重新编码为 UTF-8。使用 *no* 时,将保留原始编码。 - --refspec
-
将指定的 refspec 应用于每个导出的引用。可以指定多个 refspec。
- [<git-rev-list-args>…]
-
一个参数列表,可被 git rev-parse 和 git rev-list 接受,用于指定要导出的特定对象和引用。例如,
master~10..master
会导致导出当前 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 将尝试从存储库中删除所有识别信息,同时保留足够的原始树和历史模式以重现某些错误。目标是,在私有存储库中发现的 Git 错误将继续存在于匿名化存储库中,并且后者可以与 Git 开发人员共享以帮助解决该错误。
使用此选项,Git 将替换输出中所有的引用名称、路径、blob 内容、提交和标签消息、名称以及电子邮件地址为匿名化数据。相同字符串的两个实例将被等效替换(例如,具有相同作者的两个提交在输出中将具有相同的匿名化作者,但与原始作者字符串没有任何相似之处)。提交、分支和标签之间的关系以及提交时间戳将被保留(但提交消息和引用名称与原始内容没有任何相似之处)。树的相对构成也将被保留(例如,如果您有一个包含 10 个文件和 3 个树的根树,则输出也将如此),但它们的名称和文件内容将被替换。
如果您认为发现了 Git 错误,可以首先导出整个存储库的匿名化流
$ git fast-export --anonymize --all >anon-stream
然后确认该错误是否仍存在于从该流创建的存储库中(许多错误不会,因为它们确实取决于确切的存储库内容)
$ git init anon-repo $ cd anon-repo $ git fast-import <../anon-stream $ ... test your bug ...
如果匿名化存储库显示该错误,则值得将 anon-stream
与常规 bug 报告一起共享。请注意,匿名化流的压缩效果非常好,因此建议使用 gzip 压缩。如果您想检查流以确保其不包含任何私有数据,可以在发送前直接查阅。您可能还想尝试
$ perl -pe 's/\d+/X/g' <anon-stream | sort -u | less
它显示所有唯一行(数字转换为“X”,以将“User 0”、“User 1”等折叠为“User X”)。这会产生更小的输出,并且通常很容易快速确认流中没有私有数据。
重现某些错误可能需要引用特定的提交或路径,这在引用名称和路径被匿名化后变得具有挑战性。您可以要求某个特定令牌保持原样或映射到新值。例如,如果您有一个通过 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
。