5 ms·

They don’t use less disk space as long as you account for that correctly: clones within a file system use hardlinks for the object store, so if you du on a clon

They don’t use less disk space as long as you account for that correctly: clones within a file system use hardlinks for the object store, so if you du on a clone it’ll be however many megs / gigs S but if you do that encompassing n such clones they will only use a bit more than S for the object stores. And cross file system you can use “--shared” although that will break the clone if you remove the source (then again the same occurs with worktrees). It’s also not significantly faster: on a fairly hefty monorepo (a few gigs, working copy is 1.2G) a worktree takes 4.76s, a clone takes 4.94. The clone’s .git “is” 3.4G, but that falls to 5.8MB when du-ing both the source repository and the clone. Of course if you create every clone from the base repo it’s going to be slow as fuck and eat all your disk, but you can not do that. The rest I agree with, that objects and branches are shared between worktrees, as well as the repository configuration (e.g. remotes) is why I use worktrees, having to move things around and losing the content when I’d delete the wrong clone is why I stopped using them.

Groxx 5d ago
For anyone unfamiliar with this strategy: it's literally just "clone from a /path".
drdexebtjl 5d ago
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.
- masklinn 5d ago
  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 5d ago
  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
  - dreamcompiler 5d ago
    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.
  - epcoa 5d ago
    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.
  - drdexebtjl 5d ago
    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_002dLine-Options.html#index-_002di https://www.gnu.org/software/sed/manual/html_node/Command_00...
    - koiueo 5d ago
      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.
- jmholla 5d ago
  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 5d ago
    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.
    - deleted 5d ago
      [deleted]

Groxx 5d ago

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

drdexebtjl 5d ago

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.

masklinn 5d ago
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 5d ago
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
- dreamcompiler 5d ago
  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.
- epcoa 5d ago
  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.
- drdexebtjl 5d ago
  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_002dLine-Options.html#index-_002di https://www.gnu.org/software/sed/manual/html_node/Command_00...
  - koiueo 5d ago
    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.
jmholla 5d ago
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 5d ago
  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.
  - deleted 5d ago
    [deleted]