git clone --filter选项的语法是什么？

Question

Git 2.17更新日志描述了此选项：

• 有人介绍了克隆和获取的机制，这又涉及包装和拆包对象，该机器已被告知如何使用
  另一个主题引入的过滤机制来省略某些对象。现在
  ，它知道将生成的包标记为允诺包，以容忍丢失的
  对象，为“狭窄”克隆奠定基础。

这个标志准备好使用了吗，还是很有可能很不稳定？有谁知道正确的语法通过？我通过的所有标志都被视为无效的过滤器规范而被拒绝。例如，这些是我尝试按目录过滤的：

git clone file://path --depth=1 --filter '--subdirectory-filter Assets' TestRepo
git clone file://path --depth=1 --filter --subdirectory-filter Assets TestRepo
git clone file://path --depth=1 --filter Assets TestRepo

Answer 1

filter-spec 的格式在git rev-list --help. 你也可以在 github 上看到它。这是它目前所说的：

--filter=<过滤器规格>

仅对 --objects* 之一有用；从打印对象列表中省略对象（通常是 blob）。<filter-spec> 可能是以下之一：

该表单--filter=blob:none省略了所有 blob。

该形式--filter=blob:limit=<n>[kmg]省略了大于 n 字节或单位的 blob。n 可能为零。后缀 k、m 和 g 可用于以 KiB、MiB 或 GiB 为单位命名单位。例如，blob:limit=1k 与 blob:limit=1024 相同。

该表单--filter=sparse:oid=<blob-ish>使用 blob（或 blob 表达式）<blob-ish> 中包含的稀疏结帐规范来省略对请求的引用进行稀疏结帐不需要的 blob。

Answer 2

什么是git clone --filter选择语法？

这至少在 Git 2.27（2020 年第二季度）中更加清晰

在此之前，这是一个快速的 TLDR；该命令的示例，结合（锥形）稀疏结帐：

#fastest clone possible:
git clone --filter=blob:none --no-checkout https://github.com/git/git
cd git
git sparse-checkout init --cone
git read-tree -mu HEAD

这将只带回顶级文件夹文件，默认情况下不包括任何子文件夹。
由于该git clone --filter=blob:none --no-checkout步骤，初始克隆保持更快。

现在，进入该git clone --filter选项的语法：

请参阅Derrick Stolee ( ) 的提交 4a46544（2020 年 3 月 22 日）。^{（由Junio C Hamano合并-- --在fa0c1eb 提交中，2020 年 4 月 22 日）}derrickstolee
gitster

clone: 文件--filter选项

^{签字人：德里克·斯托利}

事实证明，“ --filter=<filter-spec>”选项没有记录在“ git clone”页面的任何地方，而是在“git rev-list”中仔细详细说明，它用于不同的目的。

在文档中添加一些关于此选项的信息。值得花一些时间在“git clone”文档中创建一个关于部分克隆作为概念以及它如何成为令人惊讶的体验的小节。例如，“git checkout”可能会触发包下载。

该混帐克隆文档现在包括：

--filter=<filter-spec>：

使用部分克隆功能并请求服务器根据给定的对象过滤器发送可访问对象的子集。

使用时--filter，提供<filter-spec>的用于部分克隆过滤器。

例如，--filter=blob:none将过滤掉所有 blob（文件内容），直到 Git 需要。
此外，--filter=blob:limit=<size>将过滤掉所有大小至少为<size>.

有关过滤器规格的更多详细信息，请参阅 中的--filter选项git rev-list。

这个选项没有我希望的那么有用。（它不能用于组合clone和filter-branch）。

然而，这种过滤机制是与 clone 相关的机制的扩展，用于实现2017 年 12 月在 Git 2.16 中引入的部分克隆（或窄克隆）。

但是您的 Git 存储库托管服务器必须支持协议 v2，目前（2018 年 10 月）仅由 GitLab 支持。

这意味着您可以使用--filterwith git clone，正如最近的 Git 2.20 补丁所示（见下文）。

然后，该过滤器被添加到git fetch在这个补丁系列。
它是新的打包协议功能“ filter”的一部分，添加到 fetch-pack 和 upload-pack 协商中。
请参阅Documentation/technical/pack-protocol 中的“过滤器”，它指的是 rev-list options。

在 Git 2.20（2018 年第 4 季度）中，配置为延迟获取丢失对象的部分克隆将按需git fetch向原始存储库发出“ ”请求以填充尚未获取的对象。
通过告诉原始存储库不需要 blob，该请求已针对请求树对象（而不是其中包含的叶 blob 对象）进行了优化。

请参阅Jonathan Tan ( ) 的commit 4c7f956和commit 12f19a9（2018 年 10 月 3 日）。^{（由Junio C Hamano合并-- --在fa54ccc 提交中，2018 年 10 月 19 日）}jhowtan
gitster

fetch-pack: 延迟获取树时排除 blob

可以使用“ git clone --filter=tree:none <repo>”获得缺少树的部分克隆。
在这样的存储库中，当需要延迟获取一棵树时，也会获取它直接或间接引用的任何树或 blob，无论原始命令是否需要这些对象，或者本地存储库是否已经拥有其中的一些对象。

这是因为延迟获取使用的获取协议不允许客户端请求仅发送想要的对象，这将是理想的解决方案。此补丁实现了部分解决方案：指定“blob:none”过滤器，在一定程度上减少了获取负载。

当延迟获取 blob 时，此更改无效（由于过滤器的工作方式）。如果懒惰地获取提交（此类存储库难以构建并且不是我们非常支持的用例，但它是可能的），仍会获取引用的提交和树 - 仅未获取 blob。

您可以通过以下方式查看进一步优化：

见提交e70a303，提交6ab4055，提交0177565，提交99bcb88（2018年9月27日）由乔纳森·谭（jhowtan）。
^{（由Junio C gitsterHamano合并-- --在commit 0527fba，2018 年 10 月 19 日）}

运输：允许跳过参考列表

该get_refs_via_connect()函数执行握手（包括确定协议版本）和获取远程引用列表。

但是，fetch 协议 v2 支持在没有 refs 列表的情况下获取对象，因此用户可以通过创建新函数来跳过列表handshake()。

请注意，随着 Git 2.21（2019 年第 1 季度）及其对协议消息规范的更新，语法已更改/演变为仅允许有限使用缩放数量。
这是确保潜在的兼容性问题不会失控。

请参阅Josh Steadmon ( )提交的 87c2d9d（2019 年 1 月 8 日）。 参见Matthew DeVore ( ) 的commit 8272f26和commit c813a7c (09 Jan 2019 )。^{（由Junio C Hamano合并-- --在提交 073312b，2019 年 2 月 5 日）}steadmon
matvore
gitster

filter-options: 展开缩放数字

当与远程服务器或子进程通信时，在对象过滤器规范中使用扩展数字而不是带有缩放后缀的数字（例如“ limit:blob=1k”变成“ limit:blob=1024”）。

更新协议文档以注意客户端应始终执行此扩展，以实现服务器实现之间的更多兼容性。

顺便invalid filter-spec说一句，Git 2.23（2019 年第三季度）认为“ ”消息是面向用户的，而不是 BUG，因此它可以本地化。

请参阅Matthew DeVore ( ) 的commit 5c03bc8（2019 年 5 月 31 日）。^{（由Junio C Hamano合并-- --在提交 ca02d36 中，2019 年 6 月 21 日）}matvore
gitster

list-objects-filter-options: 错误是可本地化的

" invalid filter-spec" 消息是面向用户的，而不是 BUG，因此请使其可本地化。

作为参考，该消息出现在此上下文中：

$ git rev-list --filter=blob:nonse --objects HEAD
fatal: invalid filter-spec 'blob:nonse'

在 Git 2.24（2019 年第 4 季度）中，http 传输缺乏一些优化，本地传输学会了避免不必要的 ref 广告，已得到修复。

请参阅Jonathan Tan ( ) 的commit fddf2eb和commit ac3fda8（2019 年 8 月 21 日）。^{（由Junio C Hamano合并-- --在提交 f67bf53 中，2019 年 9 月 18 日）}jhowtan
gitster

运输助手：如果不需要，跳过 ls-refs

Commit e70a303 (" fetch: do not list refs if fetching only hashes", 2018-10-07, Git v2.20.0-rc0) 和它的祖先教Git，作为一种优化，ls-refs在协议期间不需要时跳过这一步v2 fetch（例如，在部分克隆中延迟获取丢失的对象时，或运行“ git fetch --no-tags <remote> <SHA-1>”时）。
但这仅适用于本机支持的协议；特别是，不支持 HTTP。

教 Gitls-refs在使用支持连接或无状态连接的远程助手时跳过。

Git 2.24（2019 年第四季度）中的另一项优化

请参阅Jonathan Tan ( ) 的commit d8bc1a5 (08 Oct 2019 )。^{（由Junio C Hamano合并-- --在c7d2ced 提交中，2019 年 10 月 15 日）}jhowtan
gitster

send-pack: 检查排除项时从不获取

^{签字人：Jonathan Tan}

在构建要发送的包文件时，send_pack()会给出一个远程引用列表作为排除项。
对于每个 ref，它首先检查 ref 是否在本地存在，如果存在，则将其与“ ^”前缀一起传递给pack-objects.
但是，在部分克隆中，检查可能会触发延迟获取。

在此类获取期间获得的附加提交祖先信息可能表明服务器已经知道某些本应发送的对象，从而导致发送的包较小。
但这是以从许多可能不相关的引用中获取为代价的，并且在客户端与被推送的分支的上游保持同步的典型情况下，延迟获取根本没有帮助。

确保不会发生这些延迟获取。

最后，Git 2.24（2019 年第 4 季度）包含针对延迟获取故障的最后一分钟解决方法，它说明了filter语法的一种用法。

请参阅Jonathan Tan ( ) 的commit c7aadcc (23 Oct 2019 )。^{（由Junio C Hamano合并-- --在提交 c32ca69 中，2019 年 11 月 4 日）}jhowtan
gitster

fetch: 延迟fetch_if_missing=0到配置之后

^{签字人：Jonathan Tan}

假设，从具有“ .gitmodules”的存储库中，我们使用--filter=blob:none以下命令进行克隆：

git clone --filter=blob:none --no-checkout \
https://kernel.googlesource.com/pub/scm/git/git

然后我们获取：

git -C git fetch

这将导致“ unable to load config blob object”，因为fetch_config_from_gitmodules()调用cmd_fetch()将尝试加载“ .gitmodules”（Git 知道存在，因为客户端具有 HEAD 树）而fetch_if_missing设置为 0。

fetch_if_missing过早设置为 0 - " .gitmodules" 这里应该被延迟获取。

Git 必须fetch_if_missing在 fetch 之前设置为 0，因为作为 fetch 的一部分，packfile 协商发生（并且我们不想在检查对象存在时获取任何丢失的对象），但我们不需要那么早设置它。在任何获取发生之前，
将 的设置移动fetch_if_missing到 中的最早可能点cmd_fetch()。

在 Git 2.25（2020 年第一季度）中，对延迟克隆的调试支持有所改进。
git fetchv2 现在充分利用了promisor 文件。

请参阅Jonathan Tan ( ) 的提交 5374a29（2019 年 10 月 15 日）。^{（由Junio C Hamano合并-- --在提交 026587c 中，2019 年 11 月 10 日）}

这个答案非常冗长，除了作为字符限制的用例之外，没有任何价值。 (2认同)