Fix -v flag collision between --verbose and --version #64

New Issue

2026-08-09T03:38:52+02:00

clawbot commented

2026-08-09 03:38:52 +02:00

Context

The global --verbose flag declares a -v alias, and --version is wired
via mfa.app.Version with HideVersion = false
(internal/cli/entry.go:330,354), which gives urfave/cli its own -v.

Running mfer -v --version fails hard:

Cannot use two forms of the same flag: v version

mfer --version alone works and prints mfer version 0.1.0, so this is a
collision between the two flags rather than a broken --version. Shipping a
1.0 CLI where a plausible flag combination produces an internal-sounding
parser error is not acceptable.

Definition of done

mfer -v, mfer --verbose, mfer --version, mfer -v --version, and
mfer --verbose --version all behave sensibly and none produce a parser
error.
The chosen resolution is documented in a comment explaining which flag
owns -v and why.
mfer --version and mfer version produce identical version output.
Tests covering each of the invocations listed above, asserting exit code
and output.
make check passes. TODO.md updated in the same commit.

Implementation requirements

Decide deliberately who owns -v. Both conventions exist in the wild
(-v for verbose is more common in tools that also have -V/--version).
Pick one, state the reasoning in the comment, and be consistent across
every subcommand — not just the global flag set.
Do not resolve this by hiding or deleting --version. The release
checklist requires a working SemVer --version.
Do not resolve this by silently dropping the -v alias without saying so;
if -v stops meaning verbose, that is a user-visible change and belongs
in the commit message.
Check every subcommand's flag set for the same class of collision while
you are in here, and cover any others found.
Commit title must end with (closes #64).

## Context The global `--verbose` flag declares a `-v` alias, and `--version` is wired via `mfa.app.Version` with `HideVersion = false` (`internal/cli/entry.go:330,354`), which gives urfave/cli its own `-v`. Running `mfer -v --version` fails hard: ``` Cannot use two forms of the same flag: v version ``` `mfer --version` alone works and prints `mfer version 0.1.0`, so this is a collision between the two flags rather than a broken `--version`. Shipping a 1.0 CLI where a plausible flag combination produces an internal-sounding parser error is not acceptable. ## Definition of done - `mfer -v`, `mfer --verbose`, `mfer --version`, `mfer -v --version`, and `mfer --verbose --version` all behave sensibly and none produce a parser error. - The chosen resolution is documented in a comment explaining which flag owns `-v` and why. - `mfer --version` and `mfer version` produce identical version output. - Tests covering each of the invocations listed above, asserting exit code and output. - `make check` passes. `TODO.md` updated in the same commit. ## Implementation requirements - Decide deliberately who owns `-v`. Both conventions exist in the wild (`-v` for verbose is more common in tools that also have `-V`/`--version`). Pick one, state the reasoning in the comment, and be consistent across every subcommand — not just the global flag set. - Do not resolve this by hiding or deleting `--version`. The release checklist requires a working SemVer `--version`. - Do not resolve this by silently dropping the `-v` alias without saying so; if `-v` stops meaning verbose, that is a user-visible change and belongs in the commit message. - Check every subcommand's flag set for the same class of collision while you are in here, and cover any others found. - Commit title must end with ` (closes #64)`.

clawbot added this to the 1.0.0 milestone 2026-08-09 03:38:52 +02:00

clawbot referenced this issue

2026-08-09 03:42:37 +02:00

Rewrite the stale TODO tracking in README.md and TODO.md to match reality #76

clawbot referenced this issue

2026-08-09 03:43:38 +02:00

Release mechanics for v1.0.0: version single-sourcing and tag #80

Sign in to join this conversation.