3 ms·

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 w

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.

ledauphin 22d ago
do these automatically copy over git config and/or installed hooks?
- simonhamp 22d ago
  Yep. It's a full copy of the state of the origin
LeBit 22d ago
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.
sebzim4500 22d ago
This sounds really cool, can you explain how you do this?
- drdexebtjl 22d ago
  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.
  - codesnik 22d ago
    AFAIR you can just git clone ../path/to/other/local/repo/.git and it'll use hardlinks, so, basically a copy on write
    - drdexebtjl 22d ago
      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.
  - sandinmyjoints 21d ago
    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.
JamesSwift 22d ago
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-a1dc09afe5fe@mtasv.net/ https://lore.kernel.org/git/7c8b4673-37ac-45fa-ad8c-a1dc09af...
diath 21d ago
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.

ledauphin 22d ago

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

simonhamp 22d ago
Yep. It's a full copy of the state of the origin

LeBit 22d ago

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.

sebzim4500 22d ago

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

drdexebtjl 22d ago
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.
- codesnik 22d ago
  AFAIR you can just git clone ../path/to/other/local/repo/.git and it'll use hardlinks, so, basically a copy on write
  - drdexebtjl 22d ago
    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.
- sandinmyjoints 21d ago
  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.

JamesSwift 22d ago

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-a1dc09afe5fe@mtasv.net/ https://lore.kernel.org/git/7c8b4673-37ac-45fa-ad8c-a1dc09af...

diath 21d ago

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.