4 ms·

What is the advantage of using worktrees over another checkout in another folder?

0xdky 5y ago
You will need a full repository in other directory to checkout and this will waste storage unless you share objects via alternate.
ossusermivami 5y ago
Optimizations and management really
halfdan 5y ago
Duplicate storage as already mentioned, but you will also lose the ability to merge / doff cross branches if you have separate checkouts.
- cortesoft 5y ago
  Why would you lose that ability? You can just pull from the other checkout as an upstream, right?
  - jonathanlydall 5y ago
    Worktree allows you to checkout other branches, stashes or commits which are local only / not yet pushed. What’s also great is that you don’t need to do a pull in the other folder. Before I discovered worktree, I had my repository checked out in two places, so was either pulling both constantly, or when I needed the alternate, it was often very far behind and I had to pull a lot.
- CorrectHorseBat 5y ago
  Hmm, I tried it once and iirc I couldn't see commits/branches of the other workspace without pushing and fetching so I really didn't see any difference. With different checkouts you can also easily do that by adding the other checkout as a remote.
  - dataflow 5y ago
    Something probably got messed up on your setup (or maybe you checked out a commit instead of a branch?) because you definitely can see all worktrees' branches from inside each other when using git worktree.
    - CorrectHorseBat 5y ago
      That makes sense. Now I think about it, The issue probably was that I was working in a submodule and those branches are probably not shared.
      - jonathanlydall 5y ago
        Yes, as per my other comment, I’ve noticed with submodules that the references are isolated between the different folders, but they do share the same objects in the .git folder, so you still get efficiency there in not needing to store or pull duplicate data.
  - jonathanlydall 5y ago
    Not sure what you were doing wrong, but I use worktree regularly and you can absolutely see the same commits from both the primary and worktree side. The great thing about worktrees is that everything local is still available in the worktree and vice-versa, you can even stash push on the one side and pop on the other. You also don’t need to push or pull on either side first. I have noticed that for submodules, although they share the .git folder, they don’t share references, so you can’t see local branches and stashes between the worktrees, but sub module pulls are still quicker since they share objects so those don’t need re-pulled on the other folder.
jomar 5y ago
When you're done with a worktree, you just delete it (via `git worktree remove`). Any additional branches or stashes etc are part of the repository that the worktree was part of, and they (of course) remain. When you're done working in a separately cloned repository in another folder, if you're anything like me, before deleting it (via `rm -rf`) you'll want to check very carefully for additional branches, unpushed work, anything stashed. Deleting an entire repository that's been around for a while is a risky operation in that it may have accumulated other unrelated work in addition to the current branch (which was the primary reason for the clone), and you'll want to check carefully before deleting the whole lot. Additional worktrees within the same repository are great for medium-term ephemeral separate strands of work. They can be created and removed without concern.

You will need a full repository in other directory to checkout and this will waste storage unless you share objects via alternate.

ossusermivami 5y ago

Optimizations and management really

halfdan 5y ago

Duplicate storage as already mentioned, but you will also lose the ability to merge / doff cross branches if you have separate checkouts.

cortesoft 5y ago
Why would you lose that ability? You can just pull from the other checkout as an upstream, right?
- jonathanlydall 5y ago
  Worktree allows you to checkout other branches, stashes or commits which are local only / not yet pushed. What’s also great is that you don’t need to do a pull in the other folder. Before I discovered worktree, I had my repository checked out in two places, so was either pulling both constantly, or when I needed the alternate, it was often very far behind and I had to pull a lot.
CorrectHorseBat 5y ago
Hmm, I tried it once and iirc I couldn't see commits/branches of the other workspace without pushing and fetching so I really didn't see any difference. With different checkouts you can also easily do that by adding the other checkout as a remote.
- dataflow 5y ago
  Something probably got messed up on your setup (or maybe you checked out a commit instead of a branch?) because you definitely can see all worktrees' branches from inside each other when using git worktree.
  - CorrectHorseBat 5y ago
    That makes sense. Now I think about it, The issue probably was that I was working in a submodule and those branches are probably not shared.
    - jonathanlydall 5y ago
      Yes, as per my other comment, I’ve noticed with submodules that the references are isolated between the different folders, but they do share the same objects in the .git folder, so you still get efficiency there in not needing to store or pull duplicate data.
- jonathanlydall 5y ago
  Not sure what you were doing wrong, but I use worktree regularly and you can absolutely see the same commits from both the primary and worktree side. The great thing about worktrees is that everything local is still available in the worktree and vice-versa, you can even stash push on the one side and pop on the other. You also don’t need to push or pull on either side first. I have noticed that for submodules, although they share the .git folder, they don’t share references, so you can’t see local branches and stashes between the worktrees, but sub module pulls are still quicker since they share objects so those don’t need re-pulled on the other folder.

jomar 5y ago

When you're done with a worktree, you just delete it (via `git worktree remove`). Any additional branches or stashes etc are part of the repository that the worktree was part of, and they (of course) remain. When you're done working in a separately cloned repository in another folder, if you're anything like me, before deleting it (via `rm -rf`) you'll want to check very carefully for additional branches, unpushed work, anything stashed. Deleting an entire repository that's been around for a while is a risky operation in that it may have accumulated other unrelated work in addition to the current branch (which was the primary reason for the clone), and you'll want to check carefully before deleting the whole lot. Additional worktrees within the same repository are great for medium-term ephemeral separate strands of work. They can be created and removed without concern.