I would say "both" depending on the definition of "bug". It's a feature that a subcommand which resolves to multiple names is not just detected -- the candidates are listed. Nice.

It is certainly an improvement opportunity for the subcommand resolver to discern that the candidates are all aliases for each other. I don't think I would insist that it is a bug, though.

Here's a fix attempt: https://www.fossil-scm.org/home/timeline?r=ambiguous_cmd_fix

It's on a branch because I don't know all the peculiarities of the command dispatch logic.

Another small inconsistency with the this ambiguous command check remain:

If a command is "ambiguous" with a setting and another command, it will be reported in the list of ambiguous commands.

example:

$ fossil re
fossil: ambiguous command prefix: re
fossil: could be any of: rebuild reconstruct redirect-to-https redo relative-paths remote remote-url rename reparent repo-cksum repolist-skin revert
fossil: use "help" for more information
$ fossil red
nothing to redo

redirect-to-https is listed when trying trying re, but it's a setting.

when trying with red, it resolve to redo, so it seems to correctly not considering the setting as ambiguous when there's no other ambiguous commands.

If a command is "ambiguous" with a setting and another command, it will be reported in the list of ambiguous commands.

This case is also fixed now (on the same branch).

Waiting approval to merge in trunk.

Bug or feature, you tell me!

Overall a feature, but when Richard first added the stash command, my muscle memory of typing sta for status was broken, causing no small amount of finger retraining.

when Richard first added the stash command, my muscle memory of typing sta for status was broken, causing no small amount of finger retraining.

For me it was f cha for fossil changes when the chat command was added...