Experiment on your code freely with Git worktree

13 points by felixyz

i wrote about worktrees 0 a couple years ago (and even integrating this easily with fzf!). however, i quickly began to find deficiencies in this flow: firstly, tools like cargo and npm create a directory specific cache (target or node_modules), and it was non-trivial to share this across worktrees (cargo cache is polluted by current working directory unfortunately). secondly, worktrees work poorly with git-submodules. and by poor, i mean do not work at all. you have to re-init submodules for every worktree you create.

i have since then switched to a “branchless” flow with jujutsu.

bitwalker

Same here. jj has really solved this problem so nicely IMO, it feels trivial to bounce around between changes without fear of losing work, it’s awesome.
- hjr3
  
  I bounce around in jj so much more than I ever did with git worktrees.
matklad

Yeah, using worktrees as a replacement for branches didn’t stick with me either, it was more efficient to just improve my branching workflow (using bespoke scripts rather than jj/git branchless).

I do find it hugely convenient to have O(1) worktrees for things I literally do at the same time: https://matklad.github.io/2024/07/25/git-worktrees.html
- op
  i do agree with you on this:
  
  main for looking at the pristine code,
  
  work for looking at my code,
  
  review for looking at someone else’s
  […]
  
  very convenient to have two separate copies on disk for things like reviews (run main and run review and see how the output differs etc.).
alper

Same here. I used to use worktrees but creating them in our monorepo took the better part of a minute. With jj new master I can get to work on a different feature in seconds.
- bwbuhse
  
  Maybe I’ll have to finally learn jj. I’ve been using worktrees but it takes multiple minutes for them to be made… then I have to initialize the submodules… then I have to build which takes another 30 or so minutes the first time in the new worktree.
snej

Worktrees are just an optimization, right? I mean, compared to just cloning a new copy of the repo. I can see how creating a work tree would be faster and consume less disk space, but it doesn’t enable any new functionality…?

(I tend to have two clones of my main work repo on disk. One is my main workspace, the other is for the kinds of tasks described here, where I can quickly check out a branch, make changes or run tests, then hop back to my main task.)
- mxey
  
  You also have the same branches available between all worktrees
- jlarocco
  
  Yeah, but depending on your situation, it can be a big one.
  
  The people who migrated our project to Git didn’t know any better and put our large binary dependencies and our large binary test files (CAD files) in the repo. It’s now over 22 Gb to clone it, while a worktree is only 2-3 Gb. A classic example of tech debt, but until we bite the bullet and move everything to LFS, worktrees hide the problem a bit.
  
  It also optimizes the workflow because worktrees all see each other’s branches without adding each other as remotes, which is handy as you get more worktrees.
  
  I’m not sold on the article’s “exeprimentation” aspect - I’d use branches for what he describes - but worktrees are great for comparing builds between branches (kind of experimenting, I suppose), building and reviewing pull requests, keeping specific release branches around, etc. All things people do in a single repo with branches and stashes, but there’s much less hassle with worktrees.
  
  I can have our app open in the debugger in one worktree, create a new worktree, do whatever I need to do, and delete it, without ever closing the debugger in the other worktree.
- matklad
  
  It is an optimization, but a big one. One of my frequent usages of worktrees is that I commit a functional, but unfinished change, and kick a fuzzer run in a separate worktree. git rev-parse HEAD | pbcopy and git switch -d (pbpaste) is quite a bit more convenient than doing git push pull dance.
strongoose

having experimented with worktrees, I think just re-cloning the repo is going to be more ergonomic for 90% of use cases.
LesleyLai

I use git worktree when I need to work on multiple branches at the same time. Most commonly, it is when I’m doing a major rewrite of a project, but still need to make updates or fixes to the current production branch
stig

I still feel worktrees are a solution looking for a problem. Here’s an example use case from this text:

you don’t feel comfortable stashing changes to create a new branch

I can’t imagine anyone struggling with stashing or creating branches will find using worktrees less intimidating.

Would it not be simpler to make a sibling clone instead? Cloning a local repo will use hard links to copy files under .git/objects by default to save on disk space.