[schacon]

It's a good question, I was just working on a blog post - both because worktrees are very cool and also because I think we have a nice alternative to a similar issue.

With worktrees you can have different branches in different working directories and work on them at the same time. But practically, there is very little difference to just cloning the repo twice and working on different branches in the two checkouts.

The way we're doing it, the branches are both in the same working directory at the same time.

This can have a couple of advantages - one is if you have an annoying bugfix and you need it in order to keep working on your feature, you can have them both applied but you don't have to commit one into the history of the other. You cannot do this with worktrees.

Another is trying out multiple branches together. If they don't conflict, you can essentially get the result of a multi-way merge without creating any merge artifacts. Say you merge three work in progress branches to test them together, then keep working on each independently. Also, in this case, you _know_ that you can merge them in any order and the result will work because you've actually worked on the merged tree.

[avgcorrection]

> With worktrees you can have different branches in different working directories and work on them at the same time. But practically, there is very little difference to just cloning the repo twice and working on different branches in the two checkouts.

With clones you have to fetch everything N times. You have to gc everything N times. You have to do `git config --local` N times if the config matters/affects all clones. If you need a local branch in two clones you need to synch. between them. The repository needs to be managed, which means that every clone needs to be managed. With a worktree there is nothing extra to manage.

And when you’re done you remove it via the subcommand and it’s gone.

[Tempest1981]

Reminded me of a product called Rational ClearCase:

> It uses the MultiVersion File System (MVFS) which is a virtual file system that displays specific versions of data stored. In particular, it supports dynamic views which can show an arbitrary combination of local and remote files

https://en.m.wikipedia.org/wiki/Rational_ClearCase

[devsda]

Yeah, this sounds very much like a 'view' in clearcase.

It's a good feature especially with big monorepos where it is helpful to pick and choose a known good version of specific module or subset of files without polluting the history.

Tracking good versions of every single file with huge number of files changing was a pain though.

[schacon]

I haven't used ClearCase, but from the description, I don't think it's much like a view. It's closer to IntelliJ's changelists, but without many of the limitations.

It's effectively a way to take changes you're making and pretend like you did them in worktrees without having to switch back and forth.

Or maybe, to work on several branches, achieve the merged state you want, then split the work up into reviewable branches that can be merged in any order to achieve that final state.

[devsda]

Typical use case for worktree(s) is to work on feature/hotfix branch without touching the current master/wip branch.

So, in the context of worktrees I read _"The way we're doing it, the branches are both in the same working directory at the same time"_ as having both the branch's files (not changes) available in the same worktree.

Thanks for clarifying that it is similar to changelists.