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.