根据this thread，Git sparse-checkout feature中的排除应该被实现。是吗？
假设我有以下结构：
papers/
papers/...
presentations/
presentations/heavy_presentation
presentations/...
现在我想从结帐中排除presentations/heavy_presentation，而将其余部分留在结帐中。我没有设法让这个运行。什么是正确的语法？
答案 0 :(得分：6)
可悲的是，以上都没有为我工作，所以我花了很长时间尝试sparse-checkout文件的不同组合。
在我的情况下，我想跳过使用IntelliJ IDEA配置的文件夹。
这是我做的：
运行git clone https://github.com/myaccount/myrepo.git --no-checkout
运行git config core.sparsecheckout true
使用以下内容创建.git\info\sparse-checkout
!.idea/*
!.idea_modules/*
/*
运行＆＃39; git checkout - ＆＃39;获取所有文件。
让它发挥作用的关键是在文件夹的名称之后添加/*。
我有git 1.9
答案 1 :(得分：5)
我希望下面的内容能够起作用：
/*
!presentations/heavy_presentation
但事实并非如此。我确实尝试了很多其他组合。我认为排除没有正确实施，并且它周围存在缺陷（仍然）
类似的东西：
presentations/*
!presentations/heavy_presentation
虽然有效，但您将获得没有heavy_presentation文件夹的presentation文件夹。
因此，解决方法是明确包含其他所有内容。
答案 2 :(得分：3)
我遇到了同样的问题。我用类似的东西修复它：
!presentations/heavy_presentation
presentations/*
我如何理解它有效： 它按规则读取文件规则。如果包含某些内容，则它包含包含该单词的所有路径，并且在稀疏结帐的结束之前不再更改其状态。如果你在include之前添加排除规则，我认为它会首先删除文件而不是将所有文件标记为包含。
我不完全确定，这是我根据自己的经验所做的，并一直在为我工作。我希望它会帮助别人。
答案 3 :(得分：1)
在Git 2.25（2020年第一季度）中，稀疏签出的工作树的管理获得了专用的“ sparse-checkout”命令。
因此，不仅排除子文件夹有效，而且在稀疏签出的“圆锥体”模式（使用Git 2.25）下，它也可以更快地运行。
请参见commit 761e3d2的Ed Maste (emaste)（2019年12月20日）。
请参见commit 190a65f（2019年12月13日）和commit cff4e91，commit 416adc8，commit f75a69f，commit fb10ca5，commit 99dfa6f，commit e091228，{ {3}}，commit e9de487，commit 4dcd4de，commit eb42fec，commit af09ce2，commit 96cc8ab，commit 879321e，commit 72918c1，{{3 }}，commit 7bffca9，commit f6039a9，commit d89f09c（2019年11月21日）由commit bab3c35。
请参见commit 94c0956的Derrick Stolee (derrickstolee)（2019年11月21日）。
（由commit e6152e3在Jeff Hostetler (Jeff-Hostetler)中合并，2019年12月25日）
Junio C Hamano --
gitster--：添加“圆锥”模式签名人：Derrick Stolee
随着索引中模式数量和条目数量的增长，稀疏签出功能可以具有二次性能。
如果有1,000个模式和1,000,000个条目，那么这次可能非常重要。创建一个新的布尔值配置选项 core.sparseCheckoutCone ，以表明我们希望稀疏签出文件包含更多受限制的模式。
这是与core.sparseCheckout不同的配置设置，以避免通过引入三态选项来破坏较旧的客户端。
`core.sparseCheckoutCone`:启用稀疏签出功能的“ 圆锥模式”。
当稀疏签出文件包含一组有限的模式时，此模式将提供明显的性能优势。
sparse-checkout详细信息：
圆锥形图案设置
完整的模式集允许任意模式匹配和复杂的包含/排除规则。
在更新索引时，这些可能导致O(N*M)模式匹配，其中N是模式数量，M是索引中的路径数量。为解决此性能问题，启用core.spareCheckoutCone时允许使用更多受限制的模式集。锥形图案集中可接受的图案为：
- 递归：包含目录内的所有路径。
- 父项：包含目录中紧接的所有文件。
除了以上两种模式外，我们还希望包含根目录中的所有文件。如果添加了递归模式，则所有前导目录都将作为父模式添加。
默认情况下，运行
git sparse-checkout init时，会将根目录添加为父模式。 此时，稀疏签出文件包含以下模式：/* !/*/这说：“将所有内容都包含在root中，但不包含root以下两个级别。”
然后，如果我们将文件夹A/B/C添加为递归模式，则文件夹A和A/B将作为父模式添加。
现在生成的稀疏签出文件/* !/*/ /A/ !/A/*/ /A/B/ !/A/B/*/ /A/B/C/这里，顺序很重要，因此消极模式被积极因素所取代 文件中下方显示的样式。
如果为
core.sparseCheckoutCone=true，则Git将解析期望这些类型的模式的稀疏签出文件。
如果模式不匹配，Git会发出警告。
如果格式确实符合预期格式，则Git将使用更快的哈希- 基于算法来计算sparse-checkout中的包含。
所以：
configman page：初始化并设置为圆锥模式帮助人：黄志伟
帮助人：约翰尼斯·辛德林
签名人：Derrick Stolee要使锥形图案集易于使用，请更新'
git sparse-checkoutman page'的行为。将'
--cone'标志添加到'sparse-checkout'，以设置配置选项'core.sparseCheckoutCone=true'。在锥体模式下运行'
git sparse-checkout (init|set)'时，用户只需要提供递归文件夹匹配列表。 Git将自动为前导目录添加必要的父项匹配。在圆锥模式下测试'
git sparse-checkout init'时，请检查错误流以确保我们看不到任何错误。
具体来说，我们要避免出现模式与圆锥模式不匹配的警告。
这种新的“圆锥”模式会快多少？
git sparse-checkout set：将哈希图用于圆锥图案帮助人：黄志伟
帮助人：约翰尼斯·辛德林
签名人：Derrick Stolee稀疏检出中的“圆锥模式”选项所允许的父模式和递归模式非常严格，因此我们可以避免使用正则表达式解析。一切都基于前缀匹配，因此我们可以使用哈希集存储稀疏签出文件中的前缀。检查路径时，我们可以从路径中删除路径条目，并检查哈希集是否完全匹配。
作为测试，我为Linux系统信息库创建了一个锥体模式的稀疏检出文件，该文件实际上包括每个文件。这是通过获取Linux存储库中的每个文件夹并在此处创建模式对来构建的：
/$folder/ !/$folder/*/这导致了一个稀疏签出文件，包含8,296个模式。
在此文件上运行'git read-tree -mu HEAD'具有以下性能：core.sparseCheckout=false: 0.21 s (0.00 s) core.sparseCheckout=true: 3.75 s (3.50 s)core.sparseCheckoutCone = true：0.23 s（0.01 s）
根据
clear_ce_flags()性能跟踪，上面括号中的时间对应于第一次trace2调用所花费的时间。尽管本示例人为设计，但它演示了这些模式如何减慢稀疏签出功能。
并且：
git sparse-checkout set：在锥体模式下尊重core.ignoreCase签名人：Derrick Stolee
当用户在圆锥模式下使用稀疏签出功能时，他们使用“
sparse-checkout”或“--stdin”添加模式以在stdin上逐行提供目录。 br /> 这种行为自然看起来很像用户键入“sparse-checkout”的方式如果启用了
core.ignoreCase，则“git add”将使用不区分大小写的匹配项来匹配输入。
对sparse-checkout功能执行相同的操作。在
unpack_trees()期间更新skip-worktree位时执行不区分大小写的检查。这是通过将哈希算法和哈希图比较方法更改为可选使用不区分大小写的方法来完成的。启用此功能后，散列算法的性能成本就会降低。
为了找出最坏的情况，在具有深层目录结构的存储库中运行以下命令：git ls-tree -d -r --name-only HEAD | git sparse-checkout set --stdin“ set”命令是在
core.ignoreCase禁用或启用的情况下计时的。
对于历史悠久的回购，数量是core.ignoreCase=false: 62s core.ignoreCase=true: 74s (+19.3%)为了可重复性，在Linux内核存储库上的等效测试具有以下数字：
core.ignoreCase=false: 3.1s core.ignoreCase=true: 3.6s (+16%)现在，这并不是一个完全公平的比较，因为大多数用户将使用更浅的目录来定义他们的稀疏圆锥体，并且性能从
git sparse-checkout set <dir1> <dir2> ...开始提高（“解压树：在圆锥体模式下散列更少” 2019- 11-21，Git 2.25-rc0）可以消除大部分哈希值。要进行更实际的测试，请从-r命令中删除“ls-tree”以仅存储第一级目录。
在这种情况下，Linux内核存储库分别需要0.2-0.25s，深度存储库则需要1秒（正负0.05s）。因此，我们可以证明这一变更的成本，但是对于任何合理的稀疏结帐锥来说都不太重要。
答案 4 :(得分：0)
简答：
git sparse-checkout set /* !/presentations/heavy_presentation/
git sparse-checkout init [--cone]
--cone 选项：不仅与少数模式/小型回购相关，而且与总体加速相关。需要模式的特定规范顺序，如 sparse-checkout / CONE PATTERN SET 文档所述）。以后也可以通过以下方式介绍：
git config core.sparseCheckoutCone true