From e832676d3818ed23876416c657e12e3fc740e67a Mon Sep 17 00:00:00 2001 From: Dan Date: Fri, 29 Jul 2022 22:02:56 +0000 Subject: [PATCH] Added a comment --- ...ment_14_2acf9c8a2d261ee69f3649b05581be4d._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/git-annex-find/comment_14_2acf9c8a2d261ee69f3649b05581be4d._comment diff --git a/doc/git-annex-find/comment_14_2acf9c8a2d261ee69f3649b05581be4d._comment b/doc/git-annex-find/comment_14_2acf9c8a2d261ee69f3649b05581be4d._comment new file mode 100644 index 0000000000..8cbea4da96 --- /dev/null +++ b/doc/git-annex-find/comment_14_2acf9c8a2d261ee69f3649b05581be4d._comment @@ -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? +"""]] -- 2.30.2