Root Workspaces¶
GWZ can manage the development root workspace and other GWZ-managed roots. A
root workspace is the repository that owns gwz.conf/ and coordinates member
repositories through the manifest, lock, snapshots, and tags.
Clone the complete GWZ development workspace with GWZ itself:
gwz clone https://github.com/owebeeone/gwz-dev.git gwz-dev
cd gwz-dev
gwz status
cargo test --workspace
If you are learning the product rather than contributing to it, start with the Quick Start.
In the gwz-dev development workspace, the main member directories are:
gwz-cli/: thegwzbinary, CLI docs, release scripts, and CLI tests.gwz-core/: the embeddable Rust engine, workspace artifacts, Git backend, and protocol types.taut/: schema, compiler, and protocol tooling used by GWZ.gwz.conf/: tracked GWZ root workspace metadata.dev-docs/: planning documents.
Inspect The Workspace¶
List members:
Check status before mutating anything:
For scripts:
Run Member-Local Commands¶
Run a command in every member:
Run in specific members:
Use --partial when you want all selected members attempted even if one fails:
Manage Workspace State¶
Capture a checkpoint:
Move to the lock:
Move to heads:
Preview first when the operation may touch many members:
Stage, Commit, And Push¶
Stage all changed files across repositories:
Commit with one message across repositories that have staged changes:
Push root and member refs:
Push configured members only:
Tag A Coordinated State¶
Create an annotated tag:
Push the tag to member remotes:
Check out that tag later:
Practical Rules¶
- Start with
gwz statusbefore operations that mutate members or metadata. - Use snapshots before broad changes.
- Prefer member selectors for targeted work.
- Use
--dry-runfor materialize, pull, push, tag, add, and other mutations when the effect is not obvious. - Keep root metadata changes committed when they are meant to be shared.