git-annex/doc/todo/sync_fast_import.mdwn

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.

<https://git-annex.branchable.com/todo/importing_from_special_remote_without_downloading/#comment-e3db95e073f01a05b205e26f422f5bc5>
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]]