comments

diff --git a/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_5_c7b9cbdbc4be36ea4d56a1eec13c6f34._comment b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_5_c7b9cbdbc4be36ea4d56a1eec13c6f34._comment
new file mode 100644 (file)
index 0000000..0b8f189
--- /dev/null
+++ b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_5_c7b9cbdbc4be36ea4d56a1eec13c6f34._comment
@@ -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.
+"""]]

diff --git a/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_6_aa58624e8d0de174a06c6c2c0e33dc14._comment b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_6_aa58624e8d0de174a06c6c2c0e33dc14._comment
new file mode 100644 (file)
index 0000000..488c3e6
--- /dev/null
+++ b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_6_aa58624e8d0de174a06c6c2c0e33dc14._comment
@@ -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/*'
+"""]]