Replies: 1 comment
-
|
@dvwz Parallel delivery with concurrent subagents is a supported mode. The framework uses worktree isolation per story, so each story gets its own filesystem, and a retry-with-rebase pattern at push time to handle contention on staging. It also uses So if you're seeing conflicts, either the agent isn't following the workflow correctly or you've hit an edge case the retry pattern doesn't cover. Both are worth investigating. A few things would help me diagnose this: How many concurrent stories are you running? What's your When conflicts appear, where exactly do they happen? During the rebase onto staging, during the PR merge, or somewhere else? If you can capture the Git error output the next time it happens, that would be ideal. Are the parallel stories touching overlapping files, or are they independent? Overlapping files are the main source of rebase conflicts. The retry logic handles the “someone pushed before me” case, but actual content conflicts, where two stories edit the same lines, still need to be resolved by the agent during the rebase. “Failing to deal with branches after merges” sounds like it could be related to squash-merge cleanup. After |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm having a diverse variety of issues with version control when subagents are spawned in parallel to deliver stories. It's hard to summarize them all, but conflicts appear that are hard to resolve. Other problems include failing to deal with branches after merges. I'll report more as I find them, but I can't figure out if the model is bad at version control or if more explicit prompts need to be added about when/how to manage branches. I'm using Opus 4.6.
Beta Was this translation helpful? Give feedback.
All reactions