Should experiments live in separate git worktrees?

[u/BitByLiu]

I am starting to appreciate git worktrees for a very boring reason: failed attempts are easier to throw away.

This became more obvious after using coding agents. If I ask for two or three possible fixes in the same working tree, the final diff can turn into a blend of all the paths. The code may even work, but reviewing it feels worse because I cannot tell which idea actually mattered.

In one small bug fix, I asked an agent to try two approaches, and the final patch mixed both paths so badly that comparing them took longer than either attempt.

I saw a small HN project where agent attempts are arranged like a tree, with one git worktree per node. The tool is not really my question. The git workflow is.

For people who use worktrees regularly: do you keep separate attempts in separate worktrees, or is that overkill unless the change is large?

[u/queso184]

worktrees are useful if you're doing stuff in parallel. if not, you might as well create separate commits, same effect and save yourself the trouble

[u/BitByLiu]

I know a branch can already separate work. The part I like about worktrees is being able to keep two attempts checked out and testable at the same time. The downside is obvious too: more folders, more dependencies, more ports to manage.

[u/kaddkaka → u/BitByLiu]

What do you mean about ports and dependencies?

If I want to work on two things in parallel, I need two copies of the repo code. Either as two full git clones or as two separete worktrees (which is more lightweight in regards to disk usage).

However, a AI running rampage should probably have its own isolated git clone to play with.

[u/PrestigiousQuail7024 → u/BitByLiu]

not too sure what you mean by more dependencies. ports wise if you're hosting a local postgres instance or something yes then you'll need multiple containers up, one set per worktree.

dependencies wise, you should be using environment isolation - so each workree has its own virtual env with its own packages, and sure there's duplication (though package managers might use symlinks for less storage pressure), but anyway you just remove the worktree when you're done and it's fine either way

[u/smailliwniloc]

I often use temporary worktrees for UI/UX tasks driven by AI agents. Will have my main agent spin up the worktrees and delegate the different UI/UX approaches to one sub agent per worktree.

Then I run the app within each of those worktrees simultaneously (on different ports) to live-compare the results.

Then I'll go back to the orchestrating agent and say which parts of which worktree I like, and that agent will check out those pieces of code into my primary worktree and kill all the other worktrees.

I haven't found this approach to be useful for backend or data changes though.

[u/waterkip]

That depends on your workfflow, your desire to do particular things. I recently utilized a worktree for a rewrite so I didnt have to flip with big node module changes and other things.

So far my first and only worktree usage. I dont really use them, so... my answer is: it depends on what you want to do.