Skip to content

[feat]: Merge orchestration #322

@rabanspiegel

Description

@rabanspiegel

Feature Summary

Emdash lets me spin up multiple workspaces against the same repo / files. This is great for parallelism, but the conflict avoidance via separate worktrees just defers conflicts to the moment users want to merge everything into main.

I’d like an integration layer in Emdash that understands:

  • which branches/workspaces exist
  • what each was trying to do
  • where they overlap

and helps me merge them in a sensible order, assist with conflict resolution, and run checks along the way.

Think of it as a merge orchestrator agent for multi-task workflows.

Problem or Use Case

Multiple workspaces work on the same area (e.g. auth.ts). Even if fine in isolation, merging into main ca be painful and error-prone.

Today, I have to

  • manually discover which branches exist and what they changed,
  • pick a merge order myself,
  • resolve conflicts by hand with no awareness of each workspace’s intent,
  • run tests between merges.

This negates some of the productivity gains from parallel agent work.

An Emdash-native integration flow could:

  • surface overlaps early,
  • suggest a merge order,
  • reason over conflicts,
  • and ensure tests/checks pass between steps.

Proposed Solution

  • Add an Integration view for a repo that:

    • lists all active workspace branches,
    • shows for each: branch name, files changed, short intent (workspace description), and status vs main (clean / likely conflicts).
  • In that view, Emdash:

    • analyzes diffs vs main,
    • highlights branches that touch the same files/regions,
    • suggests a merge order (e.g. “core refactor → MFA feature → metrics cleanup”) based on change type (refactor/feature/cleanup) and workspace descriptions.
  • Guided merge flow:

    • I pick one or more branches to integrate.

    • Emdash creates/uses an integration branch (e.g. auth-epic), merges branches into it in the suggested order, and:

      • runs tests/linters/typecheck after each merge,

      • when conflicts occur, calls an agent that:

        • sees both sides + base + workspace intent,
        • proposes a merged version with a short explanation,
        • lets me accept/edit/reject the resolution.
  • Output:

    • One tested integration branch ready to merge into main.
    • A log showing which branches were merged, in what order, and how conflicts were resolved.
  • Principles:

    • Branches remain small and task-focused (per current workspace model); this feature just helps integrate them.
    • Behavior is transparent: always show diffs and steps, never silently drop changes.
    • There is always a human review and easy rollback before anything lands on main.

Alternatives Considered

No response

Additional Context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions