FEATURE REQUEST
Add first-class support for managing a "working set" of independent (non-nested) Git repositories as a single logical workspace — without submodules, subtrees, or a monorepo — including a unified status/diff view, cross-repo atomic commits, and batch fetch/pull/push/branch operations.
Motivtion
Many projects are structured as a set of independently-versioned repositories by design (not out of necessity): a core repo plus a variable set of plugin/extension repos, an SDK with separate sample repos, or components with different release cycles or access permissions. Developers regularly work on a subset of these repos together — e.g., "core + extension A + extension B" — as one cohesive unit of work.
Existing Git composition mechanisms don't fit this pattern well:
Git Submodules force the parent repo to reference and pin child repos, which is unwanted here.
Git Subtree is workable but operationally awkward (merge/split commands, history handling).
Monorepo is explicitly out of scope — components are intentionally separate repos.
As a result, today this workflow requires switching between multiple repo windows/tabs/profiles in the Git client, with no shared view of status or coordinated operations across the active set of repos.
Proposed Solution
Introduce the concept of a "working set": a user-defined, named collection of repositories that can be activated together (e.g. core, ext-auth, ext-billing), independent of any Git-level linkage between them. The working set is a client-side/tool-level concept only — it does not modify repo metadata or create cross-repo references.
For an active working set, the UI should support:
Unified Status View
Single tree of modified/staged/untracked files aggregated across all repos in the working set, with each file clearly attributed to its source repo.
Diff view for any file, viewable in place, without switching tabs/panels/windows.
Cross-repo Atomic Commit
Select individual files (across any subset of repos in the working set) to stage.
Provide a single commit message that gets applied as a separate commit in each affected repo/branch.
Note: this is "atomic" from a UX standpoint (one action, one message) — not a true distributed transaction, since Git has no native cross-repo atomicity. The tool should clearly report per-repo commit success/failure (e.g., partial failure if one repo's commit fails).
Batch Remote Operations
Fetch / pull / push across all (or a selected subset of) repos in the working set via a single action.
Aggregate and surface per-repo results/errors after the batch operation (not just a single pass/fail).
Batch Branching
Create or switch to a branch (same name) across a selected subset of repos in the working set in one action.
Handle gracefully when the branch doesn't yet exist in some repos, or when repos are in a dirty state that blocks a switch.
Out of Scope
Any mechanism that creates Git-level references between repos (no submodule/subtree equivalents).
True atomic multi-repo transactions (rollback across repos) — this is a Git limitation, not something the tool needs to solve.
Monorepo conversion or merging of repo histories.
Use Cases / Motivation
Plugin architectures (core + optional extensions, each independently releasable).
SDK + sample-app repos maintained together but versioned separately.
Multi-repo projects where components have different access permissions (e.g. some repos are private/client-restricted) or release cadences.
Open Questions
How should working sets be defined/persisted (per-user config file vs. shared team config)?
Should commit messages be allowed to diverge slightly per repo (e.g. templated with repo name), or must they be identical?
How should branch-switch conflicts (dirty working tree in one repo) be surfaced — abort all, or skip-and-report?
FEATURE REQUEST
Add first-class support for managing a "working set" of independent (non-nested) Git repositories as a single logical workspace — without submodules, subtrees, or a monorepo — including a unified status/diff view, cross-repo atomic commits, and batch fetch/pull/push/branch operations.
Motivtion
Many projects are structured as a set of independently-versioned repositories by design (not out of necessity): a core repo plus a variable set of plugin/extension repos, an SDK with separate sample repos, or components with different release cycles or access permissions. Developers regularly work on a subset of these repos together — e.g., "core + extension A + extension B" — as one cohesive unit of work.
Existing Git composition mechanisms don't fit this pattern well:
Git Submodules force the parent repo to reference and pin child repos, which is unwanted here.
Git Subtree is workable but operationally awkward (merge/split commands, history handling).
Monorepo is explicitly out of scope — components are intentionally separate repos.
As a result, today this workflow requires switching between multiple repo windows/tabs/profiles in the Git client, with no shared view of status or coordinated operations across the active set of repos.
Proposed Solution
Introduce the concept of a "working set": a user-defined, named collection of repositories that can be activated together (e.g. core, ext-auth, ext-billing), independent of any Git-level linkage between them. The working set is a client-side/tool-level concept only — it does not modify repo metadata or create cross-repo references.
For an active working set, the UI should support:
Unified Status View
Single tree of modified/staged/untracked files aggregated across all repos in the working set, with each file clearly attributed to its source repo.
Diff view for any file, viewable in place, without switching tabs/panels/windows.
Cross-repo Atomic Commit
Select individual files (across any subset of repos in the working set) to stage.
Provide a single commit message that gets applied as a separate commit in each affected repo/branch.
Note: this is "atomic" from a UX standpoint (one action, one message) — not a true distributed transaction, since Git has no native cross-repo atomicity. The tool should clearly report per-repo commit success/failure (e.g., partial failure if one repo's commit fails).
Batch Remote Operations
Fetch / pull / push across all (or a selected subset of) repos in the working set via a single action.
Aggregate and surface per-repo results/errors after the batch operation (not just a single pass/fail).
Batch Branching
Create or switch to a branch (same name) across a selected subset of repos in the working set in one action.
Handle gracefully when the branch doesn't yet exist in some repos, or when repos are in a dirty state that blocks a switch.
Out of Scope
Any mechanism that creates Git-level references between repos (no submodule/subtree equivalents).
True atomic multi-repo transactions (rollback across repos) — this is a Git limitation, not something the tool needs to solve.
Monorepo conversion or merging of repo histories.
Use Cases / Motivation
Plugin architectures (core + optional extensions, each independently releasable).
SDK + sample-app repos maintained together but versioned separately.
Multi-repo projects where components have different access permissions (e.g. some repos are private/client-restricted) or release cadences.
Open Questions
How should working sets be defined/persisted (per-user config file vs. shared team config)?
Should commit messages be allowed to diverge slightly per repo (e.g. templated with repo name), or must they be identical?
How should branch-switch conflicts (dirty working tree in one repo) be surfaced — abort all, or skip-and-report?