Hacker News Reader

Comment by simonhamp | Hacker News Reader

Just use copy-on-write clones. They're way more flexible, faster and easier to reason about.

I don't get spending all this time on tooling that tries to ease working with worktrees when they're just not the right abstraction for the way we're working now.

View on HN

You are not referring to to a specific git feature, right?

You use your filesystem ability to perform a snapshot of your local git repo? Or you do a cp -reflink?

How do you handle the exposure of secrets to agents?

One thing I like about worktrees is that you get a clean copy (with share git objects though), so you have to copy over what the agent will need, not remove what you don’t want the agent to see.

You get other things like mutual exclusion, a clean baseline regardless of whats in the main directory, and potentially in the near future a way to tie into lifecycle hooks for eg creation/deletion [1]. That last part is nice in the new agentic AI era where you might want to setup/teardown local services that are isolated to those directories.

But yeah the filesystem cost is not ideal. I was just thinking about how to exclude my worktrees from timemachine backups automatically.

[1] https://lore.kernel.org/git/7c8b4673-37ac-45fa-ad8c-a1dc09af...

They are the right abstraction for people that do not want to relocate terabytes of their existing data and filesystem structure to migrate to some sort of an esoteric filesystem just so they can let a tool work "properly" according to some tech purists. I don't wanna worry about it at all, it just works behind the scenes.

This sounds really cool, can you explain how you do this?

Assuming you're using a filesystem that supports it like ZFS, Btrfs, XFS, etc, it's as simple as:

  cp -R --reflink=always /path/to/source /path/to/dest

On macOS with APFS:

  cp -R -c /path/to/source /path/to/dest

That's it. You get a copy that only stores additional space for metadata, not the files themselves.

I looked up `-c` on macOS. It says it causes cp to use clonefile(2) instead of copyfile. So I looked up clonefile(2). It says:

    NAME
         clonefile – create copy on write clones of files
    
    SYNOPSIS
    ...
    
    LIMITATIONS
         Cloning directories with these functions is strongly discouraged.  Use copyfile(3) to clone directories instead.

But no explanation of why strongly discouraged.

AFAIR you can just git clone ../path/to/other/local/repo/.git and it'll use hardlinks, so, basically a copy on write

Doesn’t that set the origin to the local repo instead of upstream?

Also, it’s not really CoW. The immutable object store is hardlinked (since it’s immutable it doesn’t really CoW, but that’s not a very important distinction). But working files are full copies, and so is the rest of .git. With a CoW filesystem you can CoW everything, including node_modules and build artifacts.

do these automatically copy over git config and/or installed hooks?

Yep. It's a full copy of the state of the origin

Reply on news.ycombinator.com