Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A local merge queue for parallel Claude Code agents

github.com

Post reply on HN
Print view View original

11–20 of 30 posts

Re: Show HN: A local merge queue for parallel Claude Code agents

#11

Post by grahamas »

barrkel wrote: post #5

A decent idea, however it seems to me a good chunk of it is because of git limitations. Have you looked jj? I'm having a much better time with jj and a workspace per subagent than I was with git and worktrees. It's still useful to have the CI gating on updating the master branch pointer, but you largely stop working with branches once you switch to jj.

What would be the gotchas of doing this? I just spent some time looking into it and it looks ideal for my workflow, but I’d never heard of jj before right now. As far as I can tell the problems would be:

1. Worse-for-humans PR history (I currently use this for major feature checkpoints and human-involved sanity checks and review)

2. Maybe some tooling issues with IDEs? Looks like it’s all there, but maybe getting it set up so that the agents aren’t committing every little thought they have might be a bit finicky? I use VS Code if anyone has a workflow recommendation there.

Re: Show HN: A local merge queue for parallel Claude Code agents

#12

Post by ithkuil »

kazinator wrote: post #7
barrkel wrote: post #5

A decent idea, however it seems to me a good chunk of it is because of git limitations. Have you looked jj? I'm having a much better time with jj and a workspace per subagent than I was with git and worktrees. It's still useful to have the CI gating on updating the master branch pointer, but you largely stop working with branches once you switch to jj.

git worktrees are a horrible misfeature; it's better to just clone multiple times (which you can do locally---space is saved by use of hard links!) So that is to say, we clone some remote upstream down to /path/A. Then we can clone file:///path/A to /path/B locally. Both A and B are fully fleded git repos; no monkeying around with worktrees. The objects are shared between them with hard links. You can edit B/.gitconf…

You're right about everything you said, but there is a flip side: with work trees you can:

1. find/list all related "clones" of the repo

2. Ensure that the same branch is not being worked on in different checkouts (which is useful if you do rebases as part of your workflow)

Worktrees force you distinguish the "main" repo from the swarm of checkouts, and if you locate or name directories with a rule you can always tell which are which.

For my own use, I built a little helper to create, list and destroy worktrees that fit in my workflow with Claude code:

https://github.com/mkmik/ccwt

Re: Show HN: A local merge queue for parallel Claude Code agents

#13

Post by throwaw12 »

idea looks nice, but can you share what's your workflow to push 90 commits/day?

I understand each commit might have different size, but I am guessing your commits == Pull Request (because you need this constant merge queue to rebase, merge, test) and each are around 40-80 lines of code (additions and removals), and you are probably not reviewing the code because at this rate even if one commit takes 2 minutes to review we are talking about 3 hours of non stop code review.

if you are not reviewing each code, probably your commits are small items and 10-20 of them are a part of single PR, then how do you sustain working across multiple projects?

Re: Show HN: A local merge queue for parallel Claude Code agents

#15

Post by barrkel »

grahamas wrote: post #11
barrkel wrote: post #5

A decent idea, however it seems to me a good chunk of it is because of git limitations. Have you looked jj? I'm having a much better time with jj and a workspace per subagent than I was with git and worktrees. It's still useful to have the CI gating on updating the master branch pointer, but you largely stop working with branches once you switch to jj.

What would be the gotchas of doing this? I just spent some time looking into it and it looks ideal for my workflow, but I’d never heard of jj before right now. As far as I can tell the problems would be: 1. Worse-for-humans PR history (I currently use this for major feature checkpoints and human-involved sanity checks and review) 2. Maybe some tooling issues with IDEs? Looks like it’s all there, but maybe getting it…

JJ stacked changes are just a chain of git commits. To jj, a branch is just a pointer to a commit, like git. Code review is no different to whatever you normally do for git. Push to your review system and review commit by commit Gerrit style, or as a single unit, or as stacked PR (I have not done this however as I don't use GitHub any more).

Re: Show HN: A local merge queue for parallel Claude Code agents

#19

Post by otekengineering »

set up a channel for agents to communicate and you shouldn't have issues with messy merges.

your force quitting is probably more from your build pipeline than anything agents are doing.

i use an m2 8gb air with no performance issues at up to 10 parallel claude code interactive sessions (ghostty), each with deep/transient subagent heirarchies that mix claude and codex.

very rarely need to force quit. only seen a couple restart-level failures, and those were on me for being cowboy with subagent delegation logic, resulting in 100s of claude moles popping up faster than i could whack them with force close.

Post reply on HN