Readme seems generated then minimized to the extreme, to a point where I cannot follow it anymore.

> The JavaScript init function initializes exactly `at`; Git-root selection and `--here` are CLI behavior.

What does this mean? Maybe I'm missing something

Also some of the stuff in this README seems like it should be in comments above/in their respected code blocks.

It also did not tell me why rift is a better alternative. Because it's fast? git worktrees are also fast.

git worktree (or any COW snapshot like this) still leaves you reinstalling node_modules per tree and fighting over a dev server port. That's the actual cost, and none of these tools touch it. So I gave up on parallelizing inside one repo. I run agents across different projects — one repo each — and stay serial within a single project.

you are right, I've experimented with cp -a on macOS as well for https://github.com/madarco/agentbox and in the end found it's actually faster to use worktrees inside docker containers while mounting your .git repo inside them.

Then after the node_modules (or apt packages) are installed, take a docker commit snapshot.

Now I have truly isolated parallel workspaces in <10s.

Also the system was easy to adapt to cloud environments as well so now I have Hetzner, Vercel, Daytona as well (using their native snapshotting systems for fast boot after the initial setup)

IIRC docker commit snapshots the container filesystem, not a true COW snapshot — though for this use case the distinction probably doesn't matter much since you're getting the same sub-10s restore behavior either way.

We hit the same wall. The node_modules problem alone killed parallel worktrees for us — disk space and install time add up fast. Separate repos per concern felt annoying at first but honestly the review overhead drops a lot.

This! A hundred times over. It's hard enough having to review one serial set of changes managing parallel changes into a single code base has been a nightmare load on my brain so I avoid that unless I'm trying to prototype something quick and dirty.

Is it just an experimental tool by opencode team? If there is some article about this tool, I would love to read it. It’s not clear to me why I should use this instead of git worktree.

It's a ~1d old experiment. Not sure why posted on hackernews.

Fair, but does age matter if it solves a real pain point? The gap between "1-day experiment" and "worth evaluating" is shorter than it used to be. Curious what specific worktree friction prompted this.

Don't see the real reason to use this, as well as readme file is too short and give no actual info what is the better versus existing tools. Can be called Yet another :D ...

I find it hard to understand what it is about. Better in what way?

this is a 1 day old vibe coded experiment where i'm exploring some ideas

I wrote something similar with go, but MacOS only.

Creating a worktree became instant, but the bottleneck shifted from that to git needing to build its index. Claude code runs `git status` in the background, meaning any speed gains are instantly gone.

Currently it just sounds like an alternative to work trees, but with no explanation on how it’s better. Seems early stages, use of btrfs is cool, but unsure why I’d use this right now

Digging in I now see how btrfs will also copy over non git tracked files, e.g. target/ dir. this is super nice actually.

If that achieves quick COW copies of whole repo and works on Mac OS that's the solution I've been looking for last few weeks. Internets and Claude were insisting that such copies are possible only on Linux via OverlayFS. Seamless switching between unrelated features in the same repo – here I come!

No. XFS too - `cp --reflink=auto`. or LVM / ZFS snapshots if you will

Love to see btrfs subvolumes getting used!!

I spent some time & tokens starting to work on jujutsu support for opencode. Whose workspace support is so so good. I wonder if JJ does reflink-- maybe gonna go add that, as low hanging fruit.

Neat! Would a similar approach work with ZFS instead of btrfs?

With btrfs, you can freely create subvolumes and snapshots anywhere (including nested inside of each other), you can have thousands of them without any noticeable performance impact, and you can easily convert a snapshot to a writable subvolume. I don't have much experience with ZFS, but from reading another post [0], my impression is that this isn't really doable with ZFS. And based off of rift's Readme, I think that these features are required for it to work. But I'm not an expert, so I may be mistaken about something here.

[0]: https://news.ycombinator.com/item?id=45077119

ZFS snapshots would work great, assuming you enjoy reading documentation for three days.

Could be good option for rust projects with huge compile artifacts. Saving space and rebuild time.

Will this replace /warp in Opencode? Seeing as it's made by the same team

Brought to you by the infamous author of yet another llm harness - will exfiltrate all your data, then feign ignorance:

https://github.com/anomalyco/opencode/issues/10416

Search issues for "privacy" and some very worrying discussions are there.

Include closed issues, as some have been closed without resolution.

Does it work well when we have gitsubmodules?

I had some issues regarding that.

finalyy the claude blocking edits on wrktree might be solved

Worktrees still leave you context-switching mid-feature with uncommitted work everywhere. We tried them for a month and ended up back on stash. If Rift handles dirty working trees better, that's the real pitch.