Added a comment
This commit is contained in:
parent
29f6b19525
commit
e832676d38
1 changed files with 12 additions and 0 deletions
|
@ -0,0 +1,12 @@
|
|||
[[!comment format=mdwn
|
||||
username="Dan"
|
||||
avatar="http://cdn.libravatar.org/avatar/986de9e060699ae70ff7c31342393adc"
|
||||
subject="comment 14"
|
||||
date="2022-07-29T22:02:56Z"
|
||||
content="""
|
||||
Ah, I hadn't considered the parallel to the standard `find` command, but now that you mention that I understand where you're coming from and can appreciate why `whereis` is free of this association.
|
||||
Still, I would think that a user who, after looking at the docs for `git annex find`, specified `--all` because they wanted to operate on keys would not be surprised.
|
||||
|
||||
I notice that the man page for `git annex find` already has a \"SEE ALSO\" reference to `git annex whereis`.
|
||||
Could this be expanded so that it more clearly and prominently advises the reader who is looking to query against all known keys to check out the `--all` argument to `git annex whereis` as well as its `--format=` option if \"whereis\" information is not actually of interest?
|
||||
"""]]
|
Loading…
Reference in a new issue