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

importtree: support preferred content expressions needing keys

Browse source 
When importing from a special remote, support preferred content expressions
that use terms that match on keys (eg "present", "copies=1"). Such terms
are ignored when importing, since the key is not known yet.

When "standard" or "groupwanted" is used, the terms in those
expressions also get pruned accordingly.

This does allow setting preferred content to "not (copies=1)" to make a
special remote into a "source" type of repository. Importing from it will
import all files. Then exporting to it will drop all files from it.

In the case of setting preferred content to "present", it's pruned on
import, so everything gets imported from it. Then on export, it's applied,
and everything in it is left on it, and no new content is exported to it.

Since the old behavior on these preferred content expressions was for
importtree to error out, there's no backwards compatability to worry about.
Except that sync/pull/etc will now import where before it errored out.
This commit is contained in:
Joey Hess 2023-12-18 16:27:26 -04:00
parent 0e161a7404
commit 9a67ed0f10
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
8 changed files with 94 additions and 54 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/todo/import_tree_preferred_content_expansions.mdwn
View file

@ -13,3 +13,5 @@ key evaluate to true. Then it would import all files
turn out that the special remote doesn't want to contain particular content
that was imported from it, and it would make sense that an export to the
special remote would remove those files. --[[Joey]]
> [[done]] --[[Joey]]

29
doc/todo/import_tree_preferred_content_expansions/comment_1_df8ca8665e1dfc530a832b6d24d60ea4._comment Normal file
View file

@ -0,0 +1,29 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2023-12-18T18:02:40Z"
content="""
Hmm, consider for example a camera. If the user wants to import all jpeg
files from it, and not export to it jpeg files that have a copy in an
archive, they might use:
not copies=archive:1 and include=*.jpeg
But on import, if "copies=archive:1" were made to evaluate to true
as suggested here, then this expression would not match, and so
nothing would be imported.
Seems that the approach needs to be instead to traverse the expression
and prune terms that operate on keys. So convert the example
above to "include=*.jpeg".
How to prune in some other cases:
not (copies=archive:1 and copies=backup:1) => anything
not (copies=archive:1 and include=*.jpeg) => not (include=*.jpeg)
not (copies=archive:1 or include=*.jpeg) => not (include=*.jpeg)
not ((not copies=archive:1) or include=*.jpeg) => not (include=*.jpeg)
"""]]