--location and --clear-location together silently clear

Symptom

--location and --clear-location are not declared mutually exclusive, and when both are given the
clear silently wins.

src/cli.rs declares them as independent flags. In src/commands/assets.rs the --location branch
sets the patch, and the --clear-location branch immediately afterwards overwrites it — with no
error and no warning.

imogen assets edit <id> --location 50.1,-5.5 --clear-location

Observed: the asset's location is cleared, exit 0. The user asked for two contradictory things and
got one of them chosen for them, silently.

Expected

clap refuses the combination, the way it already does for --to / --unassign on
imogen people reassign:

#[arg(long, conflicts_with = "clear_location")]

An explicit refusal, not a silent precedence rule. Losing a location the user asked to set is the
wrong way round for a tie-break, and a script that builds its arguments conditionally can produce
this pair without anyone intending it.

Affected repos

Only this one. Nothing on the wire changes.

Context

Found by review during the imogen-sdk v0.5.0 pin move. Pre-existing and unrelated to that change —
the review surfaced it while reading the surrounding code rather than the diff.

Related: #30 (an empty --to resolving to the first named person) is the same shape — an argument
combination that should be refused and instead resolves to something arbitrary.

Fixed in #37 (squashed to main).

--location now carries conflicts_with = "clear_location", so it is clap's own refusal rather than a hand-rolled check, following people reassign's --to / --unassign as you suggested:

$ imogen edit asset-1 --location 50.1,-5.5 --clear-location
error: the argument '--location <LOCATION>' cannot be used with '--clear-location'
exit 2

Review turned up that --location was one of three identical pairs in the same build_patch. --captured-at with --reset-captured-at reached the server as both, and the server takes the reset branch and drops the date the person typed; -d with --clear-description sent a null. Both now carry conflicts_with too, so no branch in build_patch can overwrite another.

--favorite/--no-favorite and --archive/--unarchive deliberately keep overrides_with: last-wins on a repeatable boolean is a POSIX idiom and is deterministic, not the arbitrary resolution this issue is about.

Noted in the PR under ## Found, not fixed: imogen album update -d "new text" --clear-description is this same contradiction in a different command — AlbumArgs::Update declares no conflicts_with either.

Refuse an album name and a flag pair that cannot mean anything (#44)

Navigation Menu

Repository navigation

--location and --clear-location together silently clear #32

Symptom

Expected

Affected repos

Context

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

--location and --clear-location together silently clear #32

Description

Symptom

Expected

Affected repos

Context

Activity

ergofobe commented on Sep 15, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions