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, import --no-content largefiles conflict

done --Joey