3 ms·
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 di
by 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 agoSomething 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 agoThat 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 agoYes, 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 agoNot 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.