import --no-content: Check annex.largefiles

Import small files into git, the same as is done when importing with content.
Which means, for small files, --no-content does download them.

If the largefiles expression needs the file content available
(due to mimetype or mimeencoding being used), the import will fail.

This commit was sponsored by Jake Vosloo on Patreon.
This commit is contained in:
Joey Hess 2020-09-28 13:22:16 -04:00
parent 8b74f01a26
commit 15c1ee16d9
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
6 changed files with 106 additions and 53 deletions

View file

@ -91,7 +91,8 @@ the tree of files on the remote, even when importing into a subdirectory.
* `--content`, `--no-content`
Controls whether content is downloaded from the special remote.
Controls whether annexed content is downloaded from the special remote.
The default is to download content into the git-annex repository.
With --no-content, git-annex keys are generated from information
@ -108,16 +109,12 @@ the tree of files on the remote, even when importing into a subdirectory.
The annex.securehashesonly configuration, if set, will prevent
--no-content importing from a special remote that uses insecure keys.
Using --no-content prevents annex.largefiles from being checked,
because the files are not downloaded. So, when using --no-content,
files that would usually be considered non-large will be added to the
annex, rather than adding them directly to the git repository.
Note that a different git tree will often be generated when using
Note that a different git tree may be generated when using
--no-content than would be generated when using --content, because
the options cause different kinds of keys to be used when importing
new/changed files. So mixing uses of --content and --no-content can
lead to merge conflicts in some situations.
lead to merge conflicts in some situations. Some special remotes,
notably the directory special remote, avoid this problem.
# IMPORTING FROM A DIRECTORY

View file

@ -13,6 +13,13 @@ expression needs the file content, when importing from a special remote.
Or could detect when those are used, and only allow
importing with --content in that case.
> So this needs a way to introspect a preferred content expression
> to see if the terms used in it
> match some criteria. Another todo that also needs that is
> [[faster_key_lookup_for_limits]] --[[Joey]]
> > That introspection is implemented now.
Which is better? The repo may have annex.largefiles set in gitattributes
for good workflow reasons, so it would be very annoying to have importing
error out. And if importing ignores the configuration, the user is likely
@ -21,9 +28,8 @@ and say "sorry, I can't, need the file content", the user can then choose
between changing largefiles or using --content, and it's clear how they're
asking for contradictory things.
> So this needs a way to introspect a preferred content expression
> to see if the terms used in it
> match some criteria. Another todo that also needs that is
> [[faster_key_lookup_for_limits]] --[[Joey]]
Hmm, if largefiles does not match, it would have to download the file
content to add it to git, even though --no-content is used. A little weird,
but it's a small file, presumably.
> > That introspection is implemented now.
[[done]] --[[Joey]]