Yeah, when you had multiple agents working on the same machine, branch isolation was no longer sufficient.

A repository folder can only be on one branch at a time.

A worktree is basically equivalent to a cp -R + git branch, which allows this new workflow to occur.

I loved this particular historical insight as to why `git worktree` was added in 2015:

Before worktrees, kernel devs faced a major inconvenience when switching contexts, e.g., stopping feature work to fix an urgent bug on a release branch.

Running git stash and switching branches alters timestamps on thousands of files.

This forces `make` to perform a full re-compile, which can take up to an hour on large kernels.

I use a skill that basically boils down to 'keep track of ongoing work in a json file, create a new numbered clone for each separate thread of work, delete when done'. Worktrees are too opaque and not entirely isolated for my liking.

I still don't understand how people use git worktrees with Docker. You need a full database and etc. For me it's simpler to have multiple checkouts.

And the team behind opencode is working on an alternative https://github.com/anomalyco/rift

How small are people’s projects if they find worktrees useful? I use them for hobby stuff, but $DAYJOB is a different story because of testing

I set up multiple work trees in one vscode workspace last year and wrote in the agents.md how to merge branches - but I spend about a third of the time helping agents integrate and merge. I remember wishing the tooling would catch up

i have some fun experiments i'm doing with full virtualization middle ware of all sys calls for agents tools/shell commands/io, still far from daily driver, but allows me to do a very rich overlay / virtual file system tom foolery in place

I have moved from my own awkward scripts to lazyworktree TUI and I loved it

I can barely keep up with one single thread and branch, go figure.

best tool yet!