alt.hn

6/1/2026 at 6:53:27 AM

Rift: Better Alternative to Git Worktrees

https://github.com/anomalyco/rift

by f4n4tiX

6/1/2026 at 9:03:54 AM

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.

by ramon156

6/1/2026 at 9:31:28 AM

The AI instructions in the `specs.md` file gave me a couple clues, e.g. `at` is the directory where the worktree should be created.

And it's clearly using btrfs subvolumes for managing a collection of related Git working trees; there's a concept of "parent" and "child" worktrees.

I don't yet understand why it's better than worktrees, other than being theoretically instant to create new ones (which could, I suppose, be a noticeable speedup if your repo is very very large).

But yeah, some more hand-written instructions in the README would definitely be helpful. I'd be particularly interested to learn whether some of the common "gotchas" one can run into with worktrees are solved by Rift or not. (E.g., I've never needed to move my "root" git repo, but apparently that causes problems because the worktrees then can't find the root repo; does Rift deal with that situation correctly?)

by rmunn

6/1/2026 at 10:30:05 AM

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

by throwwwll

6/1/2026 at 8:25:58 PM

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

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

by ryncewynd

6/1/2026 at 10:50:06 AM

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.

by zjy71055

6/1/2026 at 11:22:08 AM

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.

by jarym

6/1/2026 at 6:22:48 PM

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.

by orf

6/1/2026 at 12:27:04 PM

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 ...

by lanycrost

6/1/2026 at 10:22:45 AM

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.

by sbinnee

6/1/2026 at 10:46:57 AM

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

by simonklee

6/1/2026 at 2:40:08 PM

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

by thdxr

6/1/2026 at 9:29:48 AM

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

by rippeltippel

6/1/2026 at 10:34:40 AM

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

by pure-orange

6/1/2026 at 10:43:46 AM

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

by pure-orange

6/1/2026 at 9:38:23 AM

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!

by luckymate

6/1/2026 at 9:52:04 AM

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

by mikroskeem

6/1/2026 at 5:55:07 PM

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

by apex_sloth

6/1/2026 at 8:56:31 AM

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

by pikdum

6/1/2026 at 9:14:43 AM

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

by gucci-on-fleek

6/1/2026 at 9:45:18 AM

How about cp --reflink? Supported by btrfs, bcachefs and zfs. It's quite not as fast as subvolumes in btrfs, but it should be plenty fast.

This should actually be a feature for git itself, if it's not already.

by _flux

6/1/2026 at 9:57:32 AM

That reflinks the files, which should get you the space savings, but I'm pretty sure that that still has to recursively copy every file in the directory, which can be fairly slow if you have tens of thousands of files, whereas btrfs snapshots can reflink the directory itself, so it should be faster.

Buy yeah, this should be equivalent in most cases, since I can't imagine that many Git repos have enough files for the difference to be noticeable.

by gucci-on-fleek

6/1/2026 at 10:15:42 AM

I don't have a reflink-able filesystem in this host, but I just tested that

    echo 2 | sudo tee /proc/sys/vm/drop_caches
    time cp -rl foo bar

took 2.6 seconds for 273000 files, so I think it's highly manageable. Reflinking might be a bit slower than hardlinking, though.

by _flux

6/1/2026 at 9:46:49 AM

Also you can create and destroy (assuming the 'user_subvol_rm_allowed' mount option) BTRFS subvolumes without being root.

by andoma

6/1/2026 at 9:32:39 AM

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

by singiamtel

6/1/2026 at 9:57:36 AM

Does it work well when we have gitsubmodules?

I had some issues regarding that.

by rubnogueira

6/1/2026 at 3:44:25 PM

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.

by jauntywundrkind

6/1/2026 at 10:32:55 AM

[dead]

by huflungdung

6/1/2026 at 8:59:01 AM

[dead]

by boundless88