Metastack

One workspace, many repos. Declare the repos your project spans in metastack.yaml; metastack clones them and runs git across the set at once.

Most products don't fit in one repository: a CLI, a daemon, an update server, a Homebrew tap. metastack turns a directory into a workspace that owns that list. Declare the repos in metastack.yaml; it clones them, checks your toolchain, and runs status, pull, branch, tag and exec across the lot in one command. One binary. Nothing to install in each repo.

Why a workspace tool

Some products span several repos. Operating them by hand means a lot of cd ../foo && git pull && cd ../bar && git pull. metastack formalizes the relationship between the repos so any contributor can clone the whole workspace, verify their tools, and run cross-cutting commands without remembering which repo lives where.

How it works

Each workspace has a metastack.yaml at its root. Two required top-level keys, plus an optional provider:

• repos: — the managed repos. name becomes the directory under repos/; url is <owner>/<repo> (or a full clone URL) handed to the configured provider — gh by default, glab or plain git if you say so.
• checks: — tools metastack doctor verifies before you start working (e.g. gh, git, go, docker), each with an optional min_version floor.

Subcommands all read metastack.yaml and act on the listed repos. metastack pull runs git pull --ff-only in each; metastack status prints branch + ahead/behind + working-tree state per repo; metastack exec -- <cmd> runs an arbitrary shell command in each. The CLI walks up from the current directory to find metastack.yaml, so you can run any verb from anywhere inside the workspace.

Where to go next

• Getting started — install, scaffold a workspace, add repos, verify your toolchain.
• CLI reference — every verb, with flags and behavior.
• Configuration — the metastack.yaml schema and a worked example.