split out todo
This commit is contained in:
parent
1aec0fc6b9
commit
9e676f062f
2 changed files with 43 additions and 12 deletions
29
doc/todo/import_--no-content_largefiles_conflict.mdwn
Normal file
29
doc/todo/import_--no-content_largefiles_conflict.mdwn
Normal file
|
@ -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.
|
|
@ -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]]
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue