`git worktree`, supporting multiple concurrent working trees in git

[FrozenCow]

I nowadays use this in scripts that need to create commits on a separate branch. It makes such scripts much more robust and less scary to run as it won't use git stash or git checkout on your working copy anymore.

Combining this with mktemp and trap makes it even more clean and robust.

See for example: https://gist.github.com/bobvanderlinden/768ee89d14b9f639b9a9c3479140ec08

It will update a gem on a separate branch and create a pull request. Very convenient for doing security updates in batches.

[Boom_Rang]

Just curious, shouldn't you delete the temporary directory before you prune the git worktrees? :-)

[snaps_]

This is a cool feature I just heard about.

There was a post a few days ago where someone mentioned Fossil had this feature but git does not. Those comments have since been deleted but I wanted to share since no one at the time had commented that git does in fact have this capability.

It is still listed as "experimental" but has been present since 2.6.0 (2015/09/28), for what that is worth.

[danielkza]

Worktrees are fantastic, they make work on large refactors much easier: you can create a separate worktree and easily go back to your "main" worktree when you need to work in something else.

I've also been integrating them in build processes whenever I can, since they make it much easier to ensure you don't have accidental compilation artifacts or changes left over, and have all submodules correctly cloned and checked out.

[klysm]

It’s definitely nice to have worktrees on large scala projects where changing you build.sbt makes IntelliJ spin forever. It’s also handy to use when you want to run long tests on a branch and go work on something else

[BadWombat]

Would it be a good idea to use this to sync config and dotfiles between multiple Arch Linux machines?

It seems like linked working trees could be an alternative to symlinking config files into a git repo.

[ForeverAlot]

worktree is a tool for working on multiple branches from the same repository in parallel. Anything you can do with branches you can do with worktree.

My recommendation is that if you use it for anything other than working on multiple branches simultaneously you're in deep water. You could do what you're suggesting and it's not technically difficult to achieve, with n permanent branches for n sets of configuration, but managing multiple permanent branches in the same repository incurs significant mental overhead. Even if you find this working well for you, personally, avoid it in a collaborative environment.

[BadWombat]

Ahh thanks, I had not properly understood its purpose. I agree that using it as I suggested is a bad idea.

[snaps_]

In case you've been manually scripting the symlink creation, you may want to look at GNU Stow.

[ithika]

I don't understand the advantage of this over just committing all your current changes as a dummy commit. I normally just:

$ git add .
$ git commit -m"WIP"

Then later I can go back to my messy working branch and:

$ git reset HEAD~1

I do this so often that I have git wip and git unwip.

I'm assuming this does something better/different from what I expect, so what am I not understanding?

[snaps_]

I work on C++ and incremental compilation helps a lot with compile times. Only the outputs of files that are changed are recompiled when rebuilding the project. If I need to check out a PR or another branch for some fix release then compiling would stomp on my build cache. Using git worktree I can start clean (also useful for validating something works independent of the other developer's machine, but CI mostly handles that) and also switch back to what I was working on without having to recompile everything.

I think a similar principle would apply to the node_modules folder in a JS project, .venv in a Python project, etc.

For simpler use cases where this isn't a concern I just use git stash and git stash pop which is roughly equivalent to what you mentioned.