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

21–30 of 30 posts

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

#21

Post by 4b11b4 »

otekengineering wrote: post #19

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 coupl…

In codex threads can inspect each other, rename themselves , send each other messages. communication is default primitive

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

#22

Post by 4b11b4 »

Lately I just use an isolated worktree per conversation and I have all these threads sitting which need to be merged then I just let codex orchestrate that itself.

I tell each thread to name itself with a prefix and it's picked up by a merge queue thread which instructs them merge one at a time. Each thread has to look at the main ref as it's changed since they did their work and determine what kind of merge needs to happen. To safely merge a a variety of merge types I have a commit skill which details the process for forward reconstruction, for example.

As of yesterday I have a single voice orchestrator thread which then can poke other threads as well as the merge queue thread.

Sometimes I just do stuff in working copy when I know exactly where in the history it's going to land (I rewrite history extensively to know cleanly where that it) and I'll git absorb / jj absorb it manually.

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

#23

Post by funador »

ElijahLynn wrote: post #10

Definitely going to look into this! I just built something pretty much in the same vein of this with Claude over the past 2 months. It's a custom deployment system that uses work trees and each work tree has to to run end-to-end tests (Playright, Supabase, Astro) and other tests and create a stamp based on the contents of the entire tree. And then if another work tree has the same digest that matches the stamp then i…

Sweet, let me know how it goes. Really appreciate any feedback

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

#24

Post by funador »

throwaw12 wrote: post #13

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 revi…

Definitely not reviewing the code when 90 commits go in a day :)

I have local test suite of unit / arch / e2e / build / lint / tsc when it merges to dev. Then the same suite runs on a merge to main which pushes to prod. I have post main-push e2e that checks for regressions and automatically rolls back.

Each suite run takes 3-4 minutes so I can usually push through 15 or so commits an hour fully tested and cleanly.

I do not use PRs with this workflow, and if something breaks I add tests to prevent it happening again rather than altering the setup.

Most of the commits are for a side project (https://hola.career/) so I afford to a bit more loose than I would in professional capacity.

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

#25

Post by funador »

vasanthrb wrote: post #18

One thing I'm wondering: have you tried this on a team with multiple humans as well, or is it mainly optimized for a single developer coordinating a bunch of Claude Code agents?

There are a ton of places this package would not be suitable :)

I have not used this on a team, and what you would end up with is likely a giant PR with all those local commits that no one wants to review. Eventually someone might hold their nose and press the approve button. But that would probably be the end of the package at that workplace.

This is optimized for one engineer that does not have the machine capacity to run multiple lanes of their check test suites locally at once and also does want to pay for GHA minutes on a free plan to run those suites in the cloud.

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

#27

Post by kazinator »

ithkuil wrote: post #12
kazinator wrote: post #7

Earlier quoted context omitted.

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 tel…

> Ensure that the same branch is not being worked on in different checkouts

worktrees ensure that the same local tracking branch is not being the basis for different trees. So when you do want to work on some independent things in parallel which share the same upstream branch, you have go through the annoyance of giving the local branches different names: master-2, master-alt, master-bug2359 ...

With multiple git repos instead of work trees, you just use the same name. All three of your repos can be on rev-3-branch: the same local name for the remote origin/rev-3-branch.

The most common example of this is multiple repos of the same upstream that are all on the default branch like master.

You can easily apply rebase workflow independently on all of them, and it's easily possible to add them to each other as remotes, to move commits sideways. If we commit something in repo A on master, and do a "git fetch A" in repo B, we can then easily "git cherry pick A/master" to get that commit into B's master.

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

#28

Post by funador »

otekengineering wrote: post #19

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 coupl…

I do have a pretty heavy pipe line of local tests and running more than one of those at once is what spurred me to write this package. Especially the build step.

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

#29

Post by ThomasSchijf »

4b11b4 wrote: post #22

Lately I just use an isolated worktree per conversation and I have all these threads sitting which need to be merged then I just let codex orchestrate that itself. I tell each thread to name itself with a prefix and it's picked up by a merge queue thread which instructs them merge one at a time. Each thread has to look at the main ref as it's changed since they did their work and determine what kind of merge needs to…

[dead]
Post reply on HN