mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

split out todo

Browse source
This commit is contained in:
Joey Hess 2020-09-28 10:40:13 -04:00
parent 1aec0fc6b9
commit 9e676f062f
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 43 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

29
doc/todo/import_--no-content_largefiles_conflict.mdwn Normal file
View 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.

26
doc/todo/sync_fast_import.mdwn
View file

@ -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]]