From e9c95ef890ad443968450dfafffe744ac666c02e Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 25 May 2021 11:43:46 -0400 Subject: [PATCH] comments --- ..._c7b9cbdbc4be36ea4d56a1eec13c6f34._comment | 23 +++++++++++++++++ ..._aa58624e8d0de174a06c6c2c0e33dc14._comment | 25 +++++++++++++++++++ 2 files changed, 48 insertions(+) create mode 100644 doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_5_c7b9cbdbc4be36ea4d56a1eec13c6f34._comment create mode 100644 doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_6_aa58624e8d0de174a06c6c2c0e33dc14._comment 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 index 0000000000..0b8f189617 --- /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 index 0000000000..488c3e61bc --- /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/*' +"""]] -- 2.30.2