3 ms·
Worktrees share more git state (remotes, blobs, etc.) and don't require hunting down the repository url to feed to git clone, or a network connection to use sai
by MaulingMonkey 1mo ago
Worktrees share more git state (remotes, blobs, etc.) and don't require hunting down the repository url to feed to git clone, or a network connection to use said url. While you could get the same benefit from cloning your local repository, you're then in the weird state where `origin` is a local non-bare repository.
If you're setting up long-lived checkouts that you reuse, it doesn't help much (except perhaps saving space or bandwidth) vs multiple clones and some once up-front reconfiguration. On the other hand, if you want something more temporary - and perhaps based on your current HEAD without having to hunt down a commit id to feed a subsequent git clone / git checkout command - worktrees save you some boilerplate (re)configuration.
- pydry 1mo agoif it's a my main repo where im regularly doing hotfixes in one folder while i work simultaneously on a feature branch on another I will have multiple long lived checkouts (usually 4). it makes sense to keep them warm because while cloning a new repo is almost always quick, regenerating the build artefacts from scratch each time is not.