They don’t use less disk space as long as you account for that correctly: clones...

drdexebtjl · 2026-09-11T11:18:59

Hardlinks are the wrong abstraction. You modify one copy and it changes on all linked paths. You want reflinks instead.

edit: spellchecker corrected reflinks, this is what I meant.

jmholla · 2026-09-11T15:16:39

The difference here is that git objects don't change. When you do a `git gc`, you do get new objects at new inodes, but they don't get written to the existing ones. Try this out and you'll see local git clones do indeed create hardlinks:

``` cd $(mktemp -d) git init test ( cd test; touch README.md; git add README.md; git commit -m "Test"; ) git clone test/.git test_clone find test_clone/.git/objects test/.git/objects -type f -printf "%i\t%p\n" | sort ```

You'll see the same inodes used in both clones.

drdexebtjl · 2026-09-11T15:40:30

Yeah, but this only works for the immutable object store. The rest of the tree is still copied.

CoW and reflinks let you share everything, including the non-immutable paths, and even stuff like node_modules.

masklinn · 2026-09-11T17:59:48

Not relevant to comparing clones and worktrees, both create a fresh working copy from the repository data, and object store files are not modified in place (or at all really).

koiueo · 2026-09-11T11:38:59

I believe you're wrong here. If you modify a hardlinked file, the FS will create new inodes under the hood, leaving existing ones intact. So it's like CoW. At least on ext4.

// Didn't double-check, but I've held this belief for over decade now, would be surprised to be proven wrong

drdexebtjl · 2026-09-11T13:47:46

You're about to be very surprised!

  echo old > a
  ln a b
  echo new > a  
  cat a b                   # prints "new" and "new"

Some programs like GNU sed [1] do create new inodes, but that is a property of the application, not the filesystem:

  echo old > a
  ln a b
  sed -i 'c new' a
  cat a b                   # prints "new" and "old"

With reflinks in a CoW filesystem the inodes are different from the start, but share the same underlying blocks:

  echo old > a
  cp --reflink=always a b
  ls -i a b                 # prints different inodes
  echo new > a
  cat a b                   # prints "new" and "old"

[1] https://www.gnu.org/software/sed/manual/html_node/Command_00...

koiueo · 2026-09-11T18:13:45

Cool, I love surprises :D

Thanks for examples and especially the doc link. I don't normally use hard links, and for some reason was sure that's how they behave.

Maybe my belief indeed stemmed from observing software which overwrites opened file with a new copy.

epcoa · 2026-09-11T13:26:31

No this is completely incorrect. The filesystem doesn’t break a link just if you open it. Your editor or higher level utility is free to do so (by unlinking and copying the data into a new file/inode), but this is not how the filesystem works.

dreamcompiler · 2026-09-11T12:17:55

Changing a hardlinked file changes it everywhere, unless your specific editor happens to create a new inode. Thus it depends on your editor.

CoW is similar except the new inode is created by the file system itself and is independent of the editor.

Groxx · 2026-09-11T16:37:47

For anyone unfamiliar with this strategy: it's literally just "clone from a /path".