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

comment

Browse source
This commit is contained in:
Joey Hess 2023-01-16 15:52:52 -04:00
parent 527e70fc69
commit e97da33773
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 24 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/git-annex-find/comment_17_b24572ef407439b6976ee72b2bea888f._comment
View file

@ -6,5 +6,5 @@
Reminder that this is a man page, and place to maybe ask for clarification
about that documentation. It is not a place to post feature requests.
[[todo]] would be a good place to talk about a `git-annex findkeys`.
Opened a todo, [[todo/findkeys]]
"""]]

23
doc/todo/findkeys.mdwn Normal file
View file

@ -0,0 +1,23 @@
`git-annex findkeys` would be similar to `git-annex find`, but would find
all keys in the repository, or all known keys.
[[git-annex-find]] has a long comment section with users wanting some way
to do this, but I am strongly of the opinion that `git-annex find` should
list files, not keys, like `find(1)` does. See my comments there.
--[[Joey]]
findkeys could support --format like find, but without `${file}`, and
--print0 and the json options. --batch does not seem very likely to be
useful? The other options wouldn't apply to it, except for matching options
like --in that can operate on keys.
Seems that some users are looking for a way to list all keys known to
git-annex, while other users are looking for a way to list only keys
present in the local repo. If it defaults to listing all known keys,
--in=here can be used to get the other behavior. OTOH, `git-annex find`
defaults to listing only files that are present, so it would be
a little inconsistent for findkeys to default to listing all keys.
I think I prefer the inconsistency over needing a different option than
--in=here though. --[[Joey]]
[[!tag projects/dandi]]