设置和配置
获取和创建项目
基本快照
分支与合并
共享和更新项目
检查和比较
打补丁
调试
电子邮件
外部系统
服务器管理
指南
管理
底层命令
- 2.51.1 → 2.52.0 无更改
-
2.51.0
2025-08-18
- 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> 个对象插入一次进度语句,以便 git fast-import 在导入期间显示。
- --signed-tags=(verbatim|warn-verbatim|warn-strip|strip|abort)
-
指定如何处理已签名的标签。由于导出后的任何转换(或导出期间的转换,例如排除修订版本)都会改变被签名的哈希,因此签名可能会失效。
当要求中止(这是默认值)时,此程序在遇到已签名的标签时将退出。使用strip,标签将静默地变为未签名;使用warn-strip,它们将变为未签名,但会显示警告;使用verbatim,它们将静默地导出;使用warn-verbatim(或warn,一个已弃用的同义词),它们将被导出,但您会看到警告。只有当您知道您、fast-export 或 fast-import 不会执行任何影响标签或其历史记录中任何提交的转换,或者您不在乎生成的标签将拥有无效签名时,才应使用verbatim和warn-verbatim。
- --signed-commits=(verbatim|warn-verbatim|warn-strip|strip|abort)
-
指定如何处理已签名的提交。行为与 --signed-tags 完全相同,但用于提交。默认值为 strip,这与没有此选项的早期版本此命令的行为相同。
导出时,签名以
gpgsig <git-hash-algo> <signature-format>
开头,其中 <git-hash-algo> 是 Git 对象哈希,因此是 "sha1" 或 "sha256",而 <signature-format> 是签名类型,因此是 "openpgp"、"x509"、"ssh" 或 "unknown"。
例如,对 SHA-1 提交的 OpenPGP 签名以
gpgsigsha1openpgp开头,而对 SHA-256 提交的 SSH 签名以gpgsigsha256ssh开头。虽然提交的所有签名都会被导出,但导入器可以选择只接受其中的一部分。例如,git-fast-import[1] 目前在每个 Git 哈希算法的每个提交中最多存储一个签名。
注意这是高度实验性的,并且数据流的格式将来可能会更改,恕不另行保证兼容性。 - --tag-of-filtered-object=(abort|drop|rewrite)
-
指定如何处理标签指向被过滤对象的标签。由于可以按路径限制要导出的修订版本和文件,因此标签指向的对象可能会被完全过滤掉。
当要求中止(这是默认值)时,此程序在遇到此类标签时将退出。使用drop,它将从输出中省略此类标签。使用rewrite,如果标签指向的对象是提交,它将重写标签以指向一个祖先提交(通过父提交重写;请参阅 git-rev-list[1])。
- -M
- -C
-
执行移动和/或复制检测,如 git-diff[1] 手册页中所述,并使用它在输出转储中生成重命名和复制命令。
请注意,此命令的早期版本在给出这些选项时不会抱怨,并且会产生不正确的结果。
- --export-marks=<file>
-
完成后将内部标记表转储到 <file>。标记每行一个,格式为
:markidSHA-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
-
默认情况下,运行
gitfast-exportmaster~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头。当要求中止(这是默认值)时,此程序在遇到此类提交对象时将退出。使用yes,提交消息将被重新编码为 UTF-8。使用no,将保留原始编码。 - --refspec
-
将指定的 refspec 应用于每个导出的 ref。可以指定多个。
- [<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
这会创建一个名为 other 的新分支,从 master~5..master(即,如果 master 具有线性历史,它将采用最后 5 个提交)。
请注意,这假定该修订范围引用的 blob 和提交消息都不包含字符串 refs/heads/master。
匿名化
如果给定--anonymize选项,git 将尝试从存储库中删除所有识别信息,同时保留足够的原始树和历史模式来重现某些错误。目标是,在私有存储库中找到的 git 错误将在匿名化存储库中持续存在,后者可以与 git 开发人员共享以帮助解决该错误。
使用此选项,git 将用匿名化数据替换输出中的所有 refname、路径、blob 内容、提交和标签消息、名称和电子邮件地址。相同的字符串的两个实例将被等效地替换(例如,两个具有相同作者的提交将在输出中具有相同的匿名化作者,但与原始作者字符串无关)。提交、分支和标签之间的关系得以保留,提交时间戳也得以保留(但提交消息和 refname 与原始消息无关)。树的相对构成得以保留(例如,如果根树有 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 ...
如果匿名化存储库显示了错误,则值得与 regular bug report 一起共享 anon-stream。请注意,匿名化流压缩效果很好,因此鼓励对其进行 gzip 压缩。如果您想检查流以查看它不包含任何私有数据,您可以直接在发送之前进行查看。您可能还想尝试
$ perl -pe 's/\d+/X/g' <anon-stream | sort -u | less
这将显示所有唯一的行(并将数字转换为“X”,以将“User 0”、“User 1”等合并为“User X”)。这会产生小得多的输出,并且通常很容易快速确认流中没有私有数据。
重现某些错误可能需要引用特定的提交或路径,这在 refname 和路径被匿名化后变得具有挑战性。您可以要求特定令牌保持不变或映射到新值。例如,如果您有一个在使用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。
请注意,路径和 refname 在斜杠边界处被拆分为令牌。上面的命令会将subdir/secret.c匿名化为类似path123/bar.c的内容;然后您可以在匿名化存储库中搜索bar.c以确定最终的路径名。
为了简化对最终路径名的引用,您可以映射每个路径组件;因此,如果您还将subdir匿名化为publicdir,那么最终的路径名将是publicdir/bar.c。