`release [@name ...] <tag> [notes]` does the whole chain in one step —
create the annotated tag, push it to the internal server, then push it to
each selected mirror and turn it into a release object there. Target
selection reuses pushremote's @name mechanism, so the two behave alike.
Notes are generated when none are given: the tag's own annotation when it
carries more than the default, otherwise the commit subjects since the
previous tag, capped at 50 lines. `tag add v1.0 "why this exists"` now
takes a message, which is what that fallback reads; before, the
annotation was always just the tag name.
Tags ending in -rc/-alpha/-beta/-pre are marked as pre-releases on Gitea
and GitHub. Releasing the same tag twice updates the existing release;
a tag that already points at a different commit stops the command, since
moving a published tag makes one version mean different things per
server. A repository that is not on the mirror yet is reported instead of
being created as a side effect.
Binary assets are deliberately out of scope: Gitea attaches them to the
release, GitHub uses a separate upload host, and GitLab does not host
them at all but wants a link into its package registry.
The providers differ in path shape and field names -- GitLab addresses
projects by URL-encoded path, calls the notes "description" and has no
pre-release flag -- so this comes with a recording httptest stand-in that
asserts the exact requests for all three. That harness also covers
authUser, repoExists and the auth header forms, which had no test at all.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The README had no complete list of settings, so gitkey being inert and
`remotes` being undocumented were invisible. It now carries a reference
table of every setting with its meaning and whether a project .mgshrc may
override it, kept honest by a test that checks each listed key really has
an MGSH_* override.
It also documents what mgsh expects of the git server, which was assumed
but never written down: the login directory of gituser *is* gitpath —
every remote command runs there without a cd — and archive/ has to exist
before `archive` and `clone -a` can work. Plus the per-project config,
the multi-target pushremote forms, `config`, and how the project is
derived from the working directory in command-line mode.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
mikeandClaude Opus 5