consistently use importKey when available

This avoids import with --no-content and with --content potentially
generating two different trees, leading to a merge conflict when run in
two different clones of a repo. And it's necessary groundwork to make
git-annex sync --no-content import from special remotes that support
importKey.

Only the directory special remote currently supports importKey, and it
generates the same key as git-annex usually does, so there is no
behavior change for it.

Future special remotes will need to take care when adding importKey,
if it generates different keys. Added some warnings about that to
comments.

This commit was sponsored by Noam Kremen on Patreon.
This commit is contained in:
Joey Hess 2020-09-28 15:03:15 -04:00
parent 15c1ee16d9
commit 3eaaec3113
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
6 changed files with 84 additions and 49 deletions

View file

@ -35,7 +35,18 @@ git-annex to use a different backend.
> 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..)
>
> Problem: When annex.largefiles matches file content,
> cannot use importKey. So then should sync --content not use importKey
> then, risking generating a different tree? Or should it fail, even
> though importing with content is possible?
>
> > Well, different annex.largefiles settings in different clones
> > can already risk generating a different tree on import. So,
> > the former option seems preferable.
---
See also, [[todo/import_--no-content_largefiles_conflict]]
> [[done]] --[[Joey]]