magus v0.4.2 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 the affected surface 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 surface consumes them.

See also

  • MGS1102 - a review provider that does not implement an op.
  • Review - the surfaces that report capability gaps rather than hiding them.
MGS1101capabilityvcsgitbackendbranchesreview
Last updated (70fda951)
Glossary

Workspace

The magus root directory that owns a set of projects and shared config; the unit magus operates over. See workspace.

Op

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

Buzz

The language magusfiles are written in (the .buzz engine). See engines.

Affected

The set of projects touched by a change; magus affected <target> runs a target only over them. See affected.

Conventions

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