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

comments

Browse source
This commit is contained in:
Joey Hess 2021-05-25 11:43:46 -04:00
parent 01331f0b8f
commit e9c95ef890
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 48 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

23
doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_5_c7b9cbdbc4be36ea4d56a1eec13c6f34._comment Normal file
View file

@ -0,0 +1,23 @@
[[!comment format=mdwn
username="joey"
subject="""comment 5"""
date="2021-05-25T15:14:49Z"
content="""
On the --includeifany=glob idea, that seems to suggest a preferred content
expression like includeifany=, analagous to how --include matches include=
I'm feeling a bit cautious about adding a preferred content expression for
this brand new capability.
And also unfortunately, it turned out not to be possible to prevent the
associated files db from sometimes having stale filenames in it (see
[[!commit c1b50282118520350d5328153fceedac2b8d8ed5]]). Which all current
uses of the associated files db deal with by checking the list of
associated files to see if all of them are in HEAD tree. A preferred
content expression would also have to deal with that, and that risks
slowing down evaluation of preferred content expressions generally.
So I think it's best to not add a preferred content expression,
at least until there's a use case and this has had
some time to soak.
"""]]

25
doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_6_aa58624e8d0de174a06c6c2c0e33dc14._comment Normal file
View file

@ -0,0 +1,25 @@
[[!comment format=mdwn
username="joey"
subject="""comment 6"""
date="2021-05-25T15:32:40Z"
content="""
What happens if I run `git annex drop --not-used-elsewhere foo bar` and foo
and bar have the same content?
The content is not used except for in the files I listed, so it could be
argued that the --not-used-elsewhere does not apply, and it should drop it.
But of course, that becomes a problem when dropping large directory trees.
This also makes me thing that not-used-elsewhere is too broad, maybe I want
to only avoid dropping content shared by files in bardir while dropping
foodir, and the option does not allow it.
So I do think @Ilya's on to something with his suggestion.
`git annex drop foo --excludeifany=bar` does not have the ambiguity.
I guess it's also useful for querying, potentially. Eg, if I have an inbox
and an outbox and think perhaps some things from the inbox are things I've
already dealt with before, I can find such files:
git annex find inbox --includeifany='outbox/*'
"""]]