git-annex import --no-content from a directory special remote is implemented, but git-annex sync, when run without --content, does not operate on import/export special remotes. This is inconsistent, and it would be useful if it did. describes a problem with doing that, involving merge conflicts. That should not actually happen with the directory special remote, because it generates the same key with importKey as git-annex import would. But other special remotes later using this interface might generate a key using a different hash than usual. The suggestion there is that there could be a separate config that controls whether sync does a fast import or an import with content. Then when sync is run without --content, it can do a fast import. And when run with --content, it can do a fast import, followed by getting the content. Or maybe that should just be what it always does, when a remote supports importKey? (If so, git-annex import should do the same.) Yeah, this seems better than a config. Look at it like this: The special remote makes pseudo "commits" when changes are made to it. And maybe it choses to use a 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. > 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..) > > 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]]