Debian 运行着“vcswatch”服务，用于跟踪所有设置了Vcs-Git（及其他 VCS）头的打包仓库的状态，并显示哪些仓库可能需要上传包以推送待处理的更改。
此服务产生大量数据，qa.debian.org 的临时分区已多次扩展，上次扩展到 300GB。尝试使用浅克隆（git clone --depth=50）来减少大小，仅节省了百分之几的空间。对所有仓库运行 git gc 有一定帮助，但很繁琐，且随着 Debian 的增长，仓库的大小和数量都在增加。最终作者阻止了所有检出大小超过 1GB 的仓库，唯一的解决办法还是扩展磁盘或降低阻止阈值。
由于只需要从仓库中获取少量信息，即 debian/changelog 的内容和 debian/中的其他几个文件，以及打包分支上次标记后的提交次数，所以尝试在不获取完整仓库克隆的情况下获取信息是有意义的。关于是否可以仅使用 salsa.debian.org 上的 GitLab API 来获取该信息从未得到真正回答。但在 #1032623中，Gábor Németh 建议使用git clone --filter blob:none。此方法在 bug 报告中被搁置了近一年，直到下一次“磁盘已满”事件促使作者尝试。
blob:none 过滤器使 git clone 省略所有文件，仅获取提交和树信息。在 git 运行时需要的任何 blob（文件内容）都从上游仓库透明地获取并存储在本地。这成为了一个变革性的方法，作者尝试的（较大的）仓库缩小到原始大小的 1/100。
作者进一步发现通过使用 tree:0 作为过滤器可以做得更好，这还会省略所有的树，仅在需要时在运行时获取信息。作者尝试的一些较大的仓库缩小到原始大小的 1/1000。
作者在 qa.debian.org 上部署了新选项，并安排所有仓库在下次扫描时获取新的克隆：

最初从 100%下降到 95%是作者首次尝试“阻止大于 500MB 的仓库”的结果。在那之后的一周内，git 过滤器克隆将总体磁盘消耗从近 300GB 减少到 15GB，减少了 1/20。一些仓库从 GB 级别缩小到低于 1MB。
作者或许应该让所有的 git 克隆都使用其中一个过滤器。