Need to support annex.largefiles when importing a tree from a special remote.

Note that the legacy git annex import from a directory does honor annex.largefiles.

annex.largefiles will either need to be matched by downloadImport (changing to return Either Sha Key, or by buildImportTrees).

If it's done in downloadImport, to avoid re-download of non-large files, the content identifier will need to be recorded as using the git sha1. This needs a way to encode a git sha as a key, that's a bijective mapping (so distinct from annex sha1 keys).

Problem: In downloadImport, startdownload checks getcidkey to see if the ContentIdentifier is already known, and if so, returns the key used for it before. But, with annex.largefiles, the same content might be annexed given one filename, and not annexed with another. So, the key from getcidkey might not be the right one (or there could be more than one, an annex key and a translated git key).

That argues against making downloadImport match annex.largefiles.

But, if instead buildImportTrees matches annex.largefiles, then downloadImport has already run moveAnnex on the download, so the content is in the annex. Moving it back out of the annex is difficult (there may be other files in the repo using the same key). So, downloadImport would then need to not moveAnnex, but move it to somewhere temporary. Like the gitAnnexTmpObjectLocation, but using that would be a problem if there was a file in the repo and git-annex get was run on it at the same time. So an equivilant but separate location.

Further problem: downloadImport might skip a download of a CID that's already been seen. That CID might have generated a key before. The key's content may not still be present in the local repo. Then, if buildImportTrees checks annex.largefiles and wants to add it directly to git, it won't have the content available to add to git. (Conversely, the CID may have been added to git before, but annex.largefiles matches now, and so it would need to extract the content from git only to store it in the annex, which is doable but seems pointless as it's not going to save any space.)

Would it be acceptable for annex.largefiles to be ignored if the same content was already imported from a remote earlier? I think maybe so.

Then all these problems are not a concern, and back to downloadImport checking annex.largefiles being the simplest approach, since it avoids needing the separate temp file location.

From the user's perspective, the special remote contained a file, it was already imported in the past, and the file has been renamed. It makes no more sense for importing it again to change how it's stored between git and annex than it makes sense for git mv of a file to change how it's stored.

However... If two people can access the special remote, and import from it at different times, and get different trees as a result, that might break some assumptions, might also lead to merge conflicts. --Joey

Importing updates export.log, to indicate the state of the remote (the log file could have been named better). So an annex.largefiles change would result in an export/import conflict. Such a conflict can be resolved by using git-annex export, but this could be a surprising situation for users to encounter, since there is no real conflict.

Still, this doesn't feel like a reason not to implement the feature, necessarily.

done