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.
replyThey 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.
replyThe 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.
I don't understand why worktrees either, but to each their own.
replyFor 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