Hacker News Reader

Comment by dagss | Hacker News Reader

Is there git worktree support?

With the long waits for agents to do stuff I really don't see how one can get anything done without multitasking with multiple worktrees in parallel. So I'd want support for listing the worktrees and then have a list of agents within each worktree.

Emdash and Nimbalyst have this kind of UI. Unfortunately both of them want to manage the state of each worktree group themselves; I'm looking for something that just would just call git worktree directly so that I can switch more seamlessly between CLI and IDE/TUI..

View on HN

Yes, it seems that it does though I have not yet tried it: https://herdr.dev/docs/configuration/#worktrees

I use this bash script that creates tmux windows and panes in a worktree and then undoes the process:

https://gist.github.com/iaindooley/cc8a61a1ff0fe23526c850906...

You include a script .worktree in your repo that does any copying or symlinking to setup the target directory.

It also has a headless mode so that it does the worktree operations without the tmux which I use for executing pi -p prompts in worktrees.

I haven't been able to use worktrees because when there are major conflicts I find the ai can't handle it. Often it ends up dropping a lot of code.

How do you manage that? How do you successfully navigate complex merges using ai?

Claude can easily do the merges I need (or myself manually for that matter). I guess all codebases and usecases are very different here and hard to give general advice.

But I do have many years of experience working in a larger team and it's the same problem there (just that people want to merge after some days of working). I'm not sure if AI changes the picture much vs working in a team.

Either way one has to plan ahead a bit and select tasks that are not going to trample on each other. I can typically imagine roughly what the code generated is going to be (at least what files will likely be involved in what way) and when selecting tasks to work on I take into account if it's going to likely cause conflicts.

In my experience if different branches work on different things, Claude have no issue doing "trivial" merges where you just ended up changing different aspects of the same lines. Of course, if two branches rewrite the same pieces of code there's a problem -- so don't do that..

I always rebase the worktree back to the source branch before merging, and resolve conflicts on the branch. I have a resolve conflicts skill and just say:

echo “resolve conflicts” | runpi

Where runpi is my pi -p wrapper. I’ve never had a regression from it, but it gives me a report at the end so I can double check the decisions if I need to.

The skill is basically don’t use automatic resolvers, err on the side of including both sides, refer to recent commits, missions and runfiles for context and in your report to me use real branch names not HEAD and incoming because I can never remember what those refer to.

As conceptually required, serialized work that works on the same lines of code, or fix conflicts.

git worktrees are managed by git, not the IDEs. e.g. at agentastic.dev, we use git's worktree command to create them, and they should be portable to any other IDE or app.

Of course. But I prefer IDEs that group and name the agent sessions by the worktree they are tasked with automatically.

what is the advantage of git worktree vs using a git remote set to a local file upstream.

As the sibling comments note, this is kind of off-topic to my post.

But I think git worktrees are a bit more ergonomic, I don't have to think about local vs upstream there's just one place to push.

I like to organize my projects like this:

    myproject/.repo/git  # bare repository .. my own convention..
    myproject/main       # worktrees from ../.repo/git
    myproject/feature1
    myproject/feature2

The problem I have with worktrees is when I need to switch branches to merge or something. If a work tree for any branch involved exists, git prevents me from switching to it. So, I have to go clone somewhere else, do whatever, then update everything. I really wish git didn't care about the other worktree folders contained, since it clearly doesn't anyways, since you can switch any existing worktree folder to any branch you want.

So, I no longer use worktrees, and just copy and existing/clone a new folder.

I think all my problems go away with jujustu.

I'm sure they're roughly equivalent. Parent is probably actually asking: is there native support for managing multiple checkouts/branches for parallel work (and I would add: with lifecycle hooks for create/teardown so I can have dedicated test databases etc).

What is the advantage of a git remote set to a local upstream vs a git worktree?

Reply on news.ycombinator.com