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.

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

You don't have to ditch cross-platform building entirely just to escape dependency hell

No, but it’s a nice bonus

Do you even escape dependency hell this way?

Yeah, with iOS for example, you typically need very little third party dependencies for functionality. The main ones are things like analytics, crash reports, etc

I’m not aware of any attacks on native package managers in the past 5 years. The closest would be a poisoned Xcode build in China that wasn’t downloaded from Apple a while back.

Also getting an attack on one of the platforms means at least ~half your users are safe on the other one.

I remember there being a lot of hijacked CocoaPods more recently than that Xcode attack. But supposedly Swift Package Manager is actually replacing CocoaPods now, which tbh I didn't even know until now because I've been out of that loop.

So that's good. One of my larger gripes with native Mac/iPhone dev was always needing to rely on a third-party package manager with all its quirks.

It's a developer decision. But I'd say it's easier to not use dependencies on native because there are more capable system API. I don't use any in my iOS apps, and only one dependency in 20 macOS apps.

Agree to a point, but human resource is literally the main cost in most businesses, so there's that

Conway's law also plays a big part here and it's kind of TBD to see if agentic development will minify or magnify its effects

100% with you. I'm fed up of having my M3 36GB run out of memory because I have Chrome, Slack, Discord and Claude all open at the same time

That's why I'm building SuperNative

I hate to break it to you, but we already have it: it's called PHP

Seems like you've never had to worry about accessibility in hybrid apps...

We booted react native like 10 years ago and there is not much a web does not solve. We even did solve it for the desktop users anyway even before. A simple app as Shopify with mostly static content should not be any problem to build as a web.

> you don't get native look-and-feel

You answered your own question

We're only where we are in the world of computing because of abstraction layers

It's not the layers that are the problem; they're the point.

It's the quality of those layers. React is just a poor abstraction layer

Working on this problem for the next version of NativePHP Desktop. Have dropped Electron entirely