ATM I do not see any obvious way to get a list of options supported by a special remote of a given type.
manpage says
The remote's configuration is specified by the parameters passed to this command. Different types of special remotes need different configura‐
tion values. The command will prompt for parameters as needed.
and indeed I get asked for e.g. encryption to be explicitly specified (why not to default to none). But it would not even complain if I specify some bogus (mistyped etc) option. I do not see any way (tried different --help's etc) to figure out what options any given special remote actually supports without going online to e.g. https://git-annex.branchable.com/special_remotes/rsync/ for rsync special remote. It makes configuration of special remotes not a trivial matter for new users. IMHO there should be some way (mentioned in man of initremote and enableremote) to get information about supported by the remote options, e.g. git annex getremoteopts TYPE or alike. I am not sure how it should/would work for custom special remotes since I think protocol ATM doesn't support querying for a list of configuration options. May be GETCONFIG interface command could be extended to return a list with of options with description? or some new command be added?
done as eg
git annex initremote type=rsync --whatelse.External special remotes that implement LISTCONFIGS can also be queried:
git annex inittype type=external externaltype=foo --whatelse
The remote options could be part of option parsing, and then --help would list them.
That was not originally done because the option parser was too crude to support options specific not only to a given command but to a given type of special remote, but with optparse-applicative, it could certianly be done.
I don't know about supporting it in the external special remote protocol though. Communicating the full power of applicative option parsing over that pipe would add a great deal of complexity. And it would need to retain backwards compatibility.
Also, since git-annex doesn't know the name of the external special remote to use until it's parsed the command line options, it wouldn't really be possible to use any information from externals to configure the option parsing.
Kind of feels like the simplest thing with externals would be best, and that's probably something like a "CONFIGSYNOPSIS" that lets the external answer with a preformatted string describing its options for display to the user.
(Encryption needing to be explicitly disabled is a good thing, I think; it avoids any confusion about it.)
Sweet, thanks for the feature!
I wondered, why
--whatelsewhich has no semantic relation to "parameter" or "config", and not something like--help-params,--help-configs, or--listconfigsto relate it to either PARAMS (as --help reports configs) or LISTCONFIGS protocol command?I stuggled with naming this option. I did consider something with "config" (redundant with other configs), or "parameter" or "option" (redundant with other options). It was --describe-other-params for a while but that was too long to type.
--help would be the best name, but tying it into the main option parser is impractical; amoung other things it would make tab completion need to somehow run external special remotes to get a list of their parameters!
The mnemonic for --whatelse, such as it is: You've gotten at least as far as type= (without which it won't work and will prompt for that), and want to know what else you can configure.