mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

annex.addunlocked support for tree imports

Browse source 
Honor annex.addunlocked configuration when importing a tree from a special
remote.

Note, in a --no-content import, the object file will not be populated
(usually) and so expressions that match on mime type will not match. Tested
this and it works ok, the file just ends up locked. Updated docs for the
mime expressions to mention that they can't match when the file is present

Note that in Command.Sync.pullThirdPartyPopulated, recordImportTree is
called without a AddUnlockedMatcher. Since the tree generated here is not
exposed to the user and does not contain usual filenames, there is no need
of the overhead of checking it.
This commit is contained in:
Joey Hess 2024-12-19 11:43:22 -04:00
parent 02169a1ce3
commit 29b3c7c660
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
9 changed files with 93 additions and 30 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/bugs/addunlocked_true_is_not_in_effect_for_import.mdwn
View file

@ -54,3 +54,5 @@ This was to consider using `import` for a folder with DANDI stats. For now I wil
[[!meta author=yoh]]
[[!tag projects/dandi]]
> [[fixed|done]] --[[Joey]]

11
doc/bugs/addunlocked_true_is_not_in_effect_for_import/comment_1_d8dc7bb0e6d3ae4e77a2d17ef672b3ab._comment Normal file
View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2024-12-18T19:24:38Z"
content="""
Turns out that while `git-annex import` from a directory does support
addunlocked, this was forgotten about when implementing the newer special
remote tree import.
I agree that this should be supported.
"""]]

11
doc/bugs/addunlocked_true_is_not_in_effect_for_import/comment_2_40371f91f89cc035c8edc1b719210a5c._comment Normal file
View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2024-12-19T15:31:59Z"
content="""
Note that for --no-content imports, it will not be possible for mimetype=
and mimeencoding= expressions to match.
So if addunlocked is set to such an expression, it will not match and will
add the file locked. Does not seem like a blocker.
"""]]

7
doc/bugs/addunlocked_true_is_not_in_effect_for_import/comment_3_4640377996674e1330d542354b36ef3c._comment Normal file
View file

@ -0,0 +1,7 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2024-12-19T15:34:48Z"
content="""
Implemented this.
"""]]

8
doc/git-annex-matching-expression.mdwn
View file

@ -48,6 +48,10 @@ The following terms can be used:
The MIME types are the same that are displayed by running `file --mime-type`
This only matches when the content of the file is present in the local
repository. Usually that is the case, but eg, when importing from a
special remote with --no-content, the content is usually not present.
This is only available to use when git-annex was built with the
MagicMime build flag.
@ -60,6 +64,10 @@ The following terms can be used:
The MIME encodings are the same that are displayed by running `file --mime-encoding`
This only matches when the content of the file is present in the local
repository. Usually that is the case, but eg, when importing from a
special remote with --no-content, the content is usually not present.
This is only available to use when git-annex was built with the
MagicMime build flag.