mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

add

Browse source
This commit is contained in:
Joey Hess 2019-02-07 12:16:23 -04:00
parent c0b95fd969
commit d5c435d3dc
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 30 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

30
doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/comment_1_8ea993d1acc92f3aa9594ed8e2d3ec7d._comment Normal file
View file

@ -0,0 +1,30 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2019-02-07T15:57:26Z"
content="""
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.)
"""]]