This commit is contained in:
Joey Hess 2020-07-24 14:11:08 -04:00
parent c5ea2e9d12
commit 32e1d7bc31
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 45 additions and 0 deletions

View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="joey"
subject="""comment 11"""
date="2020-07-24T17:50:03Z"
content="""
Yes, it can also happen with addurl, but I think it's less likely that two
users add the same url with and without --fast or --relaxed than that two
users sync with the same remote with and without --content.
Anyway, I opened [[sync_fast_import]].
"""]]

View file

@ -0,0 +1,34 @@
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.
Except.. --no-content means annex.largefiles is not checked, so non-large
files get added as annexed files. That's done because annex.largefiles
can contain expressions that need to examine the content of the file.
In particulat for mimetype and mimeencoding.
So there would still be a conflict potential.
May be worth removing support for matching annex.largefiles when the
expression needs the file content, when importing from a special remote.
Or could detect when those are used, and only import with --content then.