11 ms·

Sorry git worktrees are a waste of time Just keep multiple copies of the repo

by hyfgfh 6d ago

dv_dt 6d ago
I don't understand why worktrees either, but to each their own. For my purposes, the alternative with just switching branches or if parallelism is needed, full repos and remotes (including local path remotes) is just much more flexible. Clone local, branch it, optionally do anything later: push a branch back to the local repo, push it to a remote, delete local repo done. The actual code and clean merges is much more significant than worktrees vs full clones
menaerus 6d ago
Worktrees are significantly faster to use and checkout than clones. They also use much less disk space, and obviously commits made in one worktree do not require git plumbing to get them visible in another etc.
- masklinn 6d ago
  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 6d ago
    For anyone unfamiliar with this strategy: it's literally just "clone from a /path".
  - drdexebtjl 6d 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 6d 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 6d 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 6d 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 6d 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 6d ago

Sorry git worktrees are a waste of time Just keep multiple copies of the repo

by hyfgfh 6d ago

Sorry git worktrees are a waste of time Just keep multiple copies of the repo

I don't understand why worktrees either, but to each their own. For my purposes, the alternative with just switching branches or if parallelism is needed, full repos and remotes (including local path remotes) is just much more flexible. Clone local, branch it, optionally do anything later: push a branch back to the local repo, push it to a remote, delete local repo done. The actual code and clean merges is much more significant than worktrees vs full clones

menaerus 6d ago

Worktrees are significantly faster to use and checkout than clones. They also use much less disk space, and obviously commits made in one worktree do not require git plumbing to get them visible in another etc.

masklinn 6d ago
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 6d ago
  For anyone unfamiliar with this strategy: it's literally just "clone from a /path".
- drdexebtjl 6d 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 6d 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 6d 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 6d 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 6d 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 6d ago