magus v0.4.3 is out. See what's new
¶ View markdown source · ✎ Suggest an edit
2 min read

MGS1101: this VCS backend cannot answer that

magus asked the configured version-control backend a question it does not implement, so the feature reports a gap instead of an answer.

[MGS1101] hg does not report branch changes

Nothing failed. The command still ran, and everything that did not depend on the missing capability is correct.

Why

magus talks to version control through a backend registry rather than shelling out to one tool, so a workspace can be on git, hg, or something a plugin provides. Backends are not required to be equal: a capability exists when a backend can answer it, and a backend that cannot is a normal state rather than a broken install.

The reason this is a diagnostic at all is that the alternative is silence, and silence is indistinguishable from good news. The branch-overlap lookup is the clearest case:

  • "No other branch is changing these files" is reassurance. You can stop thinking about it.
  • "This backend cannot tell you which branches are changing these files" is a gap in what magus knows.

Both render as an empty list. Only one of them means you are safe, so magus names the gap rather than letting an empty result speak for it. That is the same reason a knowledge lookup distinguishes absent from unknown: a negative claim is a claim, and magus does not make one it cannot support.

Fix

There is usually nothing to fix in your workspace. A capability gap is a fact about the backend, not a misconfiguration.

  • Check that the backend is the one you meant. magus buzz -e 'import "std"; import "vcs"; fun main() > void { std\print(vcs\metadata()); } main();' reports which backend resolved for this tree.
  • Treat what the lookup would have covered as unmeasured, not as clear. Where magus says a lookup is unsupported, do the check by hand if it matters to the change in front of you.
  • Implement it, if you own the backend. The capability interfaces are small and additive: a backend advertises what it can do by satisfying one, and magus reports this code for the rest. See Review for how the Diff page consumes them.

See also

  • MGS1102: a review provider that does not implement an op.
  • Review: where a review reports capability gaps rather than hiding them.
MGS1101capabilityvcsgitbackendbranchesreview
Last updated (ebec0d8b)
Earlier changes on this page (2)

Full history ↗ · Blame source ↗

Glossary

Workspace

The magus root directory that owns a set of projects and shared config; the unit magus operates over. Workspace in full.

Op

A single tool-native command a target composes (long form: operation); the middle of the work hierarchy (Spell to Op to Target). Op in full.

Buzz

The language magusfiles are written in (the .buzz engine). Buzz in full.

Tool

An action a model can call through its host: a name, a description, a typed input and a result. magus serves its tools over MCP, each a read of the workspace model or a run of the CLI it already has. Tool in full.

Conventions

This page uses none of the site's convention markers. The full set is on the conventions page.