Rift: Better Alternative to Git Worktrees (opens in new tab)

CoW doesn't require reinstall of dependencies as they're part of the same directory tree, so should be immediately accessible (I've been using this way for a couple months now and it works fine)

The application running (port config) problem is an issue for frameworks and build tools to figure out around the shift towards multiple live working copies at once

The tools that facilitate this will win imo

I use Laravel Herd along with Polyscope (made by the same company). Together they enable CoW clones with their own dev domains - it's zero setup and works super well for my use-case

I can see a simpler version of the same thing being very neat dev experience across many stacks

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.

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)

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

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?)

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

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

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

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

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