As somebody who rarely has a “pristine” working copy I love worktrees. I usually have a “project-master” worktree that’s a pristine checkout of the
masterbranch so I can test builds and things without interference from uncommitted and temporary files.I usually just check out another copy in another directory, say I am working on Foo.
foo/is the dev playground andclean-foo/for a clean checkout from master.I know you can do it all with commands but I just find it easier to diff between directories or check how things are in master without touching the dev dir.
When you do that you can’t compare branches in the same working copy in different directories. You need to create remotes between the two working copies and push/pull between them.
e.g. “git log --graph …my-branch” or “git diff my-branch master” where my-branch and master are in different directories.
Same. The main thing I’ve been liking about it for the slower compiling languages that I mainly work in (rust, android jetpack compose), is that it leaves the
buildortargetdirectories in place. So instead ofgit checkout && clean_build_dir, and having to wait to recompile, I can justcdto that dir.
I tried using them a while back but I stopped and nowadays I just reclone. Worktrees do not work with submodules, and the setup is fragile so it’s easy to screw up your .git if you’re not careful. It’s also more trouble than it’s worth having to juggle branches if it turns out one of your worktrees is checked out at the same point you want to checkout another one
Seems handy, but all the typical git caveats apply:
- “Here’s a cool feature! NEVER USE IT THIS WAY OR YOU’LL RUIN YOUR WORKING DIRECTORY!”
- Here’s a cool feature, it’s actually old and has no standard usage so everyone you meet will be subtly misusing it differently
- Here’s why you should use my workflow instead of yours: Demonstrates a process with 2 less steps but also he skips the cleanup steps so actually its the same amount of work
Fossil also supports this out of the box: you can have as many checkouts of a repo as you want against different branches, and it tries to prevent you from accidentally nesting repositories instead of opening new checkouts.
What benefits does this provide over a cloned copy of the repository?
It’s more space efficient - you don’t get another full copy of the repo. The worktree points back to the same .git directory.
And since it’s in the same repo you can diff between branches with other worktrees without needing to setup remotes for each of them.
You can already diff between branches in a single worktree.
Yes, that’s what I said.
Then why mention setting up remotes? Why would multiple worktrees help if a worktree is not necessary for the functionality?
The question I was answering was about worktrees vs. multiple clones. With multiple clones you need to setup remotes to share branches between directories. With worktrees sharing a working copy you don’t.
No need for another full git history copy, nor submodules and settings.
every time i do this, i have to annotate the old copy somehow.
i usually use a date and months later i have no clue why i made the copy.
Yes, you should name directories descriptively. I don’t think that’s unique to repository clones.
definately not since that’s the way i learned.
the problem is that a directory named master-hotfix-vgpool01-05022022 is very difficult to remember why it was created if you looked at it today.
Then clearly it was poorly named.
so what would you name it?
Something that clearly communicates its purpose.
😄 i could have used that at the project we just finished up 🤭 it is a nice idea, having master always ready in separate worktree to keep it up to date, so that you alwys can rebase your fix or feature branch onto it
😂 I always switched to master, pulled, switched back and then did the rebase
I am obsessed in having all commits of master in my feature branch 😆
