Rift 是 opencode 团队推出的一个实验性工具，目标看起来是做 git worktree（Git 允许同一仓库并行多个工作区的功能）的替代方案。评论者从极简的 README 和 `specs.md` 里反推，它可能依赖 btrfs（Linux 上支持 CoW 子卷和快照的文件系统）来快速创建工作区，并用 parent/child worktrees 之类的结构管理它们。讨论还顺带比较了 ZFS（支持快照的文件系统）、OverlayFS（Linux 的分层文件系统）、`cp --reflink`（引用复制）和 LVM snapshot 等方案，说明大家在意的是“如何实现快速克隆”。除了速度，子模块兼容性、根仓库迁移后的稳定性，以及是否支持 Mac OS 也是评论里反复被追问的问题。
很多评论首先卡在“这到底比 git worktree 好在哪”。README 被认为像是生成后又被压缩到难以理解，`at`、`--here`、Git-root 选择等概念没有讲清楚，读完仍不知道实际流程。有人直接表示如果只是“更快”，那并不足以构成替代，因为 git worktree 本身也已经很快。大家更希望看到手写说明、代码注释，以及对常见场景的明确对比。
一些人从只言片语里推断，Rift 可能是基于 btrfs 的 subvolume 和 snapshot 来管理一组相关工作区，因此创建新副本会接近瞬时。评论里进一步比较了 ZFS、XFS 上的 `cp --reflink=auto`、LVM snapshot，认为不同文件系统都能做某种 CoW 复制，只是实现粒度和速度不同。也有人提到在 27.3 万文件上 `cp -rl` 只花了 2.6 秒，说明很多场景里 hardlink 或 reflink 已经足够快。整体争论焦点不只是“能不能做”，而是“这种做法是否真的比现有方案更有价值”。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
评论者关心的不是抽象上的“替代”，而是 Git 日常坑有没有被解决。有人直接问 gitsubmodules（Git 子模块）是否能正常工作，因为自己之前就遇到过兼容性问题。也有人提到传统 git worktree 在移动根仓库后会失去对主仓库的定位，想知道 Rift 是否能避免这类失效模式。这个讨论说明大家更在意稳定性和边界场景，而不是单纯的创建速度。
git worktree: Git 的功能，允许同一仓库同时检出多个独立工作区。
btrfs subvolume: btrfs 中可单独快照、克隆和挂载的子卷，常用于快速复制工作区。
reflink: 引用复制，复制文件时复用已有数据块，只在修改时写入新副本。
Copy-on-Write (COW): 写时复制机制，初始共享数据，发生修改时才分离出新数据。
ZFS snapshot: ZFS 的快照/克隆能力，可快速保存和复制文件系统状态。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。