After even closer inspection, _ works as expected indeed.

The reason why I was confused is that some folders with tag-b were appearing in _ because this folder was containing .jpg.jpg probably produced by accident or are thumbnails generated by some app.

After closer inspection of the view described in the previous comment, seems like the content of _ is NOT pure union of "all except tag-a and tag-b".

I was hoping that the content of "unset dir" will be _ = dir-c-children - (tag-a ∪ dir-c-children)∪(tag-b ∪ dir-c-children). Or simply _ = (dir-c-children ∪ !(tag-a ∪ tag-b).

But what I'm observing is that _ contains some dir-c-children that are also part of tag-b but not tag-c (_ = dir-c-children ∪ !(tag-a)).

After fixing long paths and running:

git annex view ?tag tag=tag-a tag=tag-b 'dir-a/dir-b/dir-c/=*'

it does exactly what I need, and produces:

/
 _/
  dir-c-children-c
 tag-a/
       dir-c-children-a
 tag-b/
       dir-c-children-b

Haven't tried to use it with tag=* but for now it's even better as I'm mostly interested in tag-a and tag-b.

Hi,

First of all thanks a lot for implementing this feature!

I was trying to combine tag-filter with a path-filter, though it doesn't do what I was expecting.

Case 1: When I filter by a directory + vadd tag then it kind of works

git annex view 'dir-a/dir-b/dir-c/?=*'
git annex vadd tag?=*

Notice: _ (unset dir) is showing after running git annex view 'dir-a/dir-b/dir-c/?=*' command. But I'm getting "path too long" on 10.20241031 in vadd.

Case 2: When I do it like this (no paths too long errors)

git annex view tag?=* 'dir-a/dir-b/dir-c/?=*'

It produces something like this:

/tag-a/
      dir-c-child-1
      dir-c-child-2
/tag-b/
     dir-c-child-1
     dir-c-child-2

It does filter directories as expected except _ (unset directory) is missing from the root and subdirectories.

Case 3: it behaves 1:1 as case 2 (no paths too long errors)

git annex view 'dir-a/dir-b/dir-c/=*'
git annex view tag?=*

The last case should illustrate why I need this - I want to have a list of files limited by path dir-a/dir-b/dir-c/ (which also preserve subdirectories in dir_c, which I also need), and then I want to group directories by tag INCLUDING "unset tag dir" in order to then assign tags to subfolders of dir_c (for those that aren't already have tags). But despite I specified tag?=* (notice the question mark), the "unset dir" does not appear.

Implemented this.

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.

You can accomplish the same thing as that pathspec with --include=*.nii.gz and it works on all git-annex commands and is a much richer language than git's pathspecs that can do a lot more besides.

So, I think it would be redundant to support git's pathspecs, and am going to close this bug.

Aha, --include and --exclude options work with --branch. So:

git annex get --branch e6888f70ed97099f83a77d5bcf3372a9a75a2b5e^ --include=*/*.nii.gz'

No need for git's pagespecs when we have git-annex-matching-options!

How feasible would it be to be able to configure the remote so that a git-annex metadata get pushed to the S3 with the objects. Something like sync-meta=mymetafield that would set x-amz-meta-mymetafield= to the value of git-annex metadata -g mymetafield --key theobjectkey, whenever the data is pushed to the S3. Thanks!

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.