3 ms·
Significantly less disk usage is the main one for me. If you have a workflow where each task has a worktree, and you have 10-15 tasks in progress, and the repo
by senkora 3y ago
Significantly less disk usage is the main one for me. If you have a workflow where each task has a worktree, and you have 10-15 tasks in progress, and the repo is a decades old monorepo, then storing only one copy of the history is a big savings.
A task could be any small thing that requires its own checkout for some possibly stupid reason, like running the regression tester or temporarily running an old version of a binary out of your dev checkout over NFS if there was a bad deploy.
- tynorf 3y agoFWIW, local git clones use hard links for object files, so share a lot of their data. https://www.git-scm.com/docs/git-clone#Documentation/git-clone.txt--l https://www.git-scm.com/docs/git-clone#Documentation/git-clo...
- anyfoo 3y agoYeah, but if you work with a central repository, when using local git clones the clones are hanging off the local repository, not the central one. Sure, you can change back origin to point to the central one again, but you still have to do a dance to sync branches among your local clones (and I’m not sure what happens to the hardlinks). worktrees just naturally basically are “views” of the same local repository, which may hang off a central repository (or not).
- tynorf 3y agoYes, that would be a different reason to prefer worktrees (that I mostly agree with). I was responding to the specific storage space claim.