Skip to content

[feat] Support Multi-Repository Workspaces (VS Code-style Multi Root Workspace) #5354

Open

Description

@OnGets45

Description

Currently, a Superset workspace is limited to a single repository.

For teams working on distributed systems (frontend + backend, microservices, shared libraries, infrastructure repositories, etc.), it is very common to work across multiple repositories simultaneously.

Modern IDEs such as VS Code, Cursor, IntelliJ IDEA, and WebStorm support opening multiple repositories within a single workspace/project, allowing developers and AI agents to understand the entire system context.

Proposed Solution

Allow a workspace to contain multiple repositories.

Example:

Heart Workspace
├── Client-Project (with a single repo)
├── Server-Project (with a single repo)
├── Shared-Library
└── Infrastructure
...

Activity

  1. added and removed
    enhancementNew feature or request
    on Jul 10, 2026
  2. mrTurkay commented on Sep 3, 2026

    @mrTurkay

    +1 on this — hitting the same wall running full-stack coding agents (e.g. Claude Code) from a parent folder that isn't itself a git repo, e.g.:

    parent-folder/
    ├── frontend/   (own .git)
    └── backend/    (own .git)
    

    Superset currently requires the workspace root to be a git repo, so the only workaround is a dummy git init in the parent — which breaks clean VCS assumptions and worktree isolation for both sub-repos.

    To make this useful for agent workflows specifically, I think two things need to hold:

    1. Allow opening a directory that isn't a git repo itself but contains nested git repos (this issue).
    2. Detect the nested repos and keep branch/worktree isolation scoped per sub-repo, while still letting an agent read across the whole parent tree for holistic context (backend API contracts + frontend implementation together).

    Related: #5796 covers the diff-view side of nested-repo detection in detail, and #1003 (closed, folded into #5594) describes a similar "monorepo of repos" layout, though it assumes the root itself has its own .git — this issue's case is the root has none at all.

    Happy to help discuss the design or contribute a PR if there's interest.

  3. harshithmullapudi commented on Sep 30, 2026

    @harshithmullapudi
    Collaborator

    #7699 -- We are working on this here, should have update in the coming week or so

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions