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:
parent
15c1ee16d9
commit
3eaaec3113
6 changed files with 84 additions and 49 deletions
|
@ -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]]
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue