正在打开每日关注
正在打开每日关注
Kache 以内容寻址缓存和复用机制降低 Rust/C/C++ 多 worktree 的磁盘与编译成本。
开发 recall,被 worktree 折腾的好烦... 开几个磁盘就开始吃紧(穷鬼套餐 500G) 发现了 Kache https://t.co/mG55qEJH9B ,新建 Rust worktree 自动复用依赖编译缓存,后续增量编译也快很多。 顺手集成进 gmc ,recall 查了下 session 历史,单用 skill gmc 已经创建过 1k+ wroktree ... 推荐给大家.
是什么
这条推文把 Kache 作为解决多 Git worktree 磁盘压力的工程工具推荐。仓库 README 将它定义为 local-first 的 Rust、C/C++ 编译缓存:按内容保存构建产物,在不同 worktree 间复用;本地存储带垃圾回收,也能通过 S3 兼容存储或文件系统远端共享。它不改变 Cargo 命令,初始化主要通过设置 rustc-wrapper 以及 C/C++ 所需环境配置接入。
核心设计
价值链条很清晰:每个 worktree 保留自己的 target 目录,同时从内容寻址缓存复用已有结果,减少重复写盘并加速增量构建。Rust 侧覆盖库、构建脚本和 Linux/macOS 可执行文件;C/C++ 侧通过编译器名称 shim 接入 Make、CMake、autotools 等调用。daemon、stats、doctor、why-miss、gc 等命令分别覆盖运行观察、诊断和容量治理;CI action 与远端缓存把本地收益延伸到团队和流水线。
关键洞察
可借鉴之处是把 worktree、缓存键、存储后端和接入方式解耦,并用 quick start、报告和基准工作流让缓存命中与存储成本可验证。README 给出的 Firefox/macOS APFS 测量称第二个 worktree 约新增 3 GB,说明其核心收益是空间效率而非单纯加速。仓库 753 stars,创建于 2026-02-15,最近提交为 2026-09-12,但这些元数据不能替代真实项目压测。
边界与风险
跨平台能力并不完全一致:Rust 可执行文件在 Windows 默认禁用;C/C++ 需要 Unix shim 或额外 CC/CXX 配置。缓存命中率、远端带宽、凭据配置、编译调用是否受支持,都会影响收益;README 也要求 benchmark job 成功且 verdict 为 ok 后才把数据当作证据。使用前应先用 kache init --check 检查变更,并确认缓存上限、远端成本和失效策略。