设置和配置
获取和创建项目
基本快照
分支和合并
共享和更新项目
检查和比较
补丁
调试
外部系统
服务器管理
指南
管理
底层命令
- 2.45.1 → 2.49.0 无更改
-
2.45.0
2024-04-29
- 2.39.1 → 2.44.3 无更改
-
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|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>
-
完成后将内部标记表转储到 <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 协议对此非常严格,并且不允许这样做。因此伪造一个标记者来快速导入输出。
- --use-done-feature
-
以一个 *feature done* 节开始流,并以一个 *done* 命令终止它。
- --no-data
-
跳过 blob 对象的输出,而是通过其原始 SHA-1 哈希引用 blob。这在重写目录结构或存储库的历史记录而不触及单个文件的内容时很有用。请注意,生成的流只能被已经包含必要对象的存储库使用。
- --full-tree
-
此选项将导致 fast-export 为每个提交发出一个 "deleteall" 指令,后跟提交中所有文件的完整列表(而不是仅列出与提交的第一个父级不同的文件)。
- --anonymize
-
匿名化存储库的内容,同时保留历史记录的形状和存储的树。请参阅下面关于
ANONYMIZING
的部分。 - --anonymize-map=<from>[:<to>]
-
在匿名输出中将 token
<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 应用于每个导出的引用。可以指定多个。
- [<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
以及常规错误报告。请注意,匿名化流压缩效果非常好,因此建议对其进行 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
。
GIT
属于 git[1] 套件的一部分