Hacker News new | ask | show | jobs
by froderick 1469 days ago
As an avid git worktree user, I use multiple checkouts for the same repo all the time. It avoids a lot of context-switching pain.
6 comments

> git worktree

Thanks, you successfully blew my mind today when I searched what this was, and learned what it was. I can't believe I've been missing out on this.

I have an application for this command today in a work project that will allow me to leave work early, so thanks for the early weekend!

Can you elaborate on some use-cases? I'm finding it hard to imagine a situation where `git worktree add <path> <commit>; do_operation_in_path <path>; git worktree remove <path` is any different than `git checkout <commit>; do_operation_in_path <path>; git checkout -`
The code base i work on takes a long time to rebuild when crossing certain points in the history, so I have persistent worktrees for the last few versions that we still support. Lets me drop into an older version for a backport without the long wait.
Suppose you have one repo with branches main, v1 and v2 (for example, releases are made from these). The branches are there forever, they are very long running branches.

Some days you work with v1 and some days with v2, and sometimes with main. Sometimes fixes are quick, sometimes not. Sometimes you must switch the working branch while you are in the middle of doing something that is not quite finished.

If you need to change between v1, v2 or main, just change a directory. Done.

So for the above example, setting up this:

  cd repo
  git checkout -b main origin/main
  git worktree add ../v1 origin/v1
  git worktree add ../v2 origin/v2
I.e. having a separate worktree for each long running branch makes working with the branches so much easier.

Edit: formatting

Ah, got it, thanks! That explains why I was confused - I've never worked in a team where long-running branches were the norm.
You're forgetting the stash command in your latter example. God help you if you're doing anything more than switching to one other branch at a time to make one small change and returning.

Also, if you're unlucky enough to be using an IDE that doesn't always handle large codebase changes well (e.g., let's say... Xcode), then you've eliminated that problem too.

It lets you efficiently have multiple checkouts of different branches at once without duplicating the actual git storage. It also lets you leave a worktree where it is while working on another - for instance, you could have editor windows in different branches at the same time, which isn't an option if you only have one checkout and have to stash+checkout to switch branches.
It's indispensible for the case of `git worktree add <path> <long-running-branch>`.
To save others the search: https://git-scm.com/docs/git-worktree
Can you compare this with the alternative of creating a lightweight alternative repo with, say:

  git-clone --reference /existing/local/repo
I discovered this a few weeks ago and it completely changed how I work with repos for the better.
I learned a thing today. I had no idea this even existed but it's awesome.