From 9e676f062f7b89ee1663f4edcba9b3268df5dfac Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 28 Sep 2020 10:40:13 -0400 Subject: [PATCH] split out todo --- ...port_--no-content_largefiles_conflict.mdwn | 29 +++++++++++++++++++ doc/todo/sync_fast_import.mdwn | 26 +++++++++-------- 2 files changed, 43 insertions(+), 12 deletions(-) create mode 100644 doc/todo/import_--no-content_largefiles_conflict.mdwn diff --git a/doc/todo/import_--no-content_largefiles_conflict.mdwn b/doc/todo/import_--no-content_largefiles_conflict.mdwn new file mode 100644 index 0000000000..e25ba52416 --- /dev/null +++ b/doc/todo/import_--no-content_largefiles_conflict.mdwn @@ -0,0 +1,29 @@ +git-annex import --no-content means annex.largefiles is not checked, so +non-large files get added as annexed files. That's done because +annex.largefiles can contain expressions that need to examine the content +of the file. In particular for mimetype and mimeencoding. + +So, if someone uses import --no-content in one repo, and in another clone +it's used with --content, importing the same files both times, a merge +conflict can result. + +May be worth removing support for matching annex.largefiles when the +expression needs the file content, when importing from a special remote. + +Or could detect when those are used, and only allow +importing with --content in that case. + +Which is better? The repo may have annex.largefiles set in gitattributes +for good workflow reasons, so it would be very annoying to have importing +error out. And if importing ignores the configuration, the user is likely +to see that as a bug. If importing with --no-content looks at the config +and say "sorry, I can't, need the file content", the user can then choose +between changing largefiles or using --content, and it's clear how they're +asking for contradictory things. + +> So this needs a way to introspect a preferred content expression +> to see if the terms used in it +> match some criteria. Another todo that also needs that is +> [[faster_key_lookup_for_limits]] --[[Joey]] + +> > That introspection is implemented now. diff --git a/doc/todo/sync_fast_import.mdwn b/doc/todo/sync_fast_import.mdwn index 653d994de2..4e28911b1c 100644 --- a/doc/todo/sync_fast_import.mdwn +++ b/doc/todo/sync_fast_import.mdwn @@ -23,17 +23,19 @@ different kind of key than the local repository would use. Same could happen when pulling from someone else's repo, if they've configured git-annex to use a different backend. -Except.. --no-content means annex.largefiles is not checked, so non-large -files get added as annexed files. That's done because annex.largefiles -can contain expressions that need to examine the content of the file. -In particulat for mimetype and mimeencoding. -So there would still be a conflict potential. +> There could be future transition problems here. If a remote does not +> support importkey, and imports are done from it, and then in a new +> version, it does support importkey, there would be the same risk of +> conflicts. +> +> Could be solved by the remote's code indicating if +> importKey is safe to use by default. If a remote started off implementing +> only imports w/o importKey, and then added importKey, and importKey +> generates different keys than the keys generated by hashing downloaded +> content, then the remote could say, don't use importKey by default. +> (Or more likely, only the directory remote will be able to support +> importKey by default..) -May be worth removing support for matching annex.largefiles when the -expression needs the file content, when importing from a special remote. -Or could detect when those are used, and only import with --content then. +--- -> So this needs a way to introspect a preferred content expression -> to see if the terms used in it -> match some criteria. Another todo that also needs that is -> [[faster_key_lookup_for_limits]] --[[Joey]] +See also, [[todo/import_--no-content_largefiles_conflict]]