From abb70e83dd4af276d22ca2d21f6b4a9558a6b1f7 Mon Sep 17 00:00:00 2001 From: EvanDeaubl Date: Mon, 22 Feb 2021 16:23:41 +0000 Subject: [PATCH] Added a comment: One possible workaround --- ...nt_2_085f54265ce94186fe715df297785496._comment | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 doc/bugs/indeterminite_preferred_content_state_for_duplicated_file/comment_2_085f54265ce94186fe715df297785496._comment diff --git a/doc/bugs/indeterminite_preferred_content_state_for_duplicated_file/comment_2_085f54265ce94186fe715df297785496._comment b/doc/bugs/indeterminite_preferred_content_state_for_duplicated_file/comment_2_085f54265ce94186fe715df297785496._comment new file mode 100644 index 0000000000..a60e229799 --- /dev/null +++ b/doc/bugs/indeterminite_preferred_content_state_for_duplicated_file/comment_2_085f54265ce94186fe715df297785496._comment @@ -0,0 +1,15 @@ +[[!comment format=mdwn + username="EvanDeaubl" + avatar="http://cdn.libravatar.org/avatar/00804f84646da416472678b573fd9d30" + subject="One possible workaround" + date="2021-02-22T16:23:40Z" + content=""" +I ran into this exact situation trying to split content across multiple repos by directory, and ran into a couple of files with many duplicate keys throughout the repo. I worked around it by applying a tag to the offending key, and including that tag as part of the preferred content expression: + +``` +git annex metadata -t common-signature $FILE_WITH_DUP_KEY +git annex wanted . 'include=\"foo/*\" or include \"bar/*\" or metadata=tag=common-signature' +``` + +This would result in a file possibly being included in a repo where it wouldn't be otherwise (if it wasn't in one of the include directories to begin with), but in my case, the common files were few and small (2, both less than 100K). +"""]]