5 ms·
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 ma
by drdexebtjl 5d 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 5d agoAFAIR you can just git clone ../path/to/other/local/repo/.git and it'll use hardlinks, so, basically a copy on write
- drdexebtjl 5d agoDoesn’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 5d agoI 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.