Live data from Hacker News

Rift: Better Alternative to Git Worktrees

github.com

1–10 of 32 posts

Re: Rift: Better Alternative to Git Worktrees

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

Re: Rift: Better Alternative to Git Worktrees

#5
post #2

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

Re: Rift: Better Alternative to Git Worktrees

#7
post #4

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 alternat…

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

Re: Rift: Better Alternative to Git Worktrees

#9
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!

Re: Rift: Better Alternative to Git Worktrees

#10
post #2

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 tha…

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.

Post reply on HN