Hey joey,
👀 Views are really cool, thanks again for this great idea. It makes managing the metadata of annexed files really fun as you can just drag files around and create, rename or delete folders.
What would make it perfect is if there was a possibility to optionally add unmatched files to a view, e.g. into a specially-named folder (like unmatched, ___unmatched___ or ????? or even configurable). Otherwise, unmatched files are not accessible from the view, so they can't be sorted into metadata from there.
Currently this is possible by default-setting the field you want to view with git annex metadata --force --set 'myfield?=???'. Then, these objects will appear in the ??? folder with git annex view myfield='*'. But that forcefully adds a value to the field, which might not be desired.
What do you think? Is something like git annex view --show-unmatched '???' worth it?
Thanks again for git-annex, I love it, it's so versatile... 💛
Yann
The existing support for "field!=value" kind of hints at a direction for this. If that supported globs (which it does not despite some now fixed docs saying it did), you could imagine this as a view where you want both files with an author and files without:
Although, it seems "!=*" would be somehow special, because "author!=Joey" would not mean that you want to put everything not authored by me in the no-author directory! So perhaps using glob syntax for this is not the right choice.
How about:
Where the '?' means make a directory for files that don't have the field set at all. So "author?=Joey" makes one directory for files authored by me, and one directory for files with no author; and all files with other authors are not included in the view.
('field?=glob' also seems a good choice because it rhymes with
git-annex metadata --set field?=value)I was going to say it seems better to avoid having any special directory name if possible, and just put files that lack a field in the parent directory that contains the directories for values of that field. But, thinking that through, I found a big problem with it. Consider this:
If a file has a year set but no author, it would need to be left in the top directory in this view. But then if it were moved to author/, it would have an author but no year, and git-annex would have to remove the year that was set. Because it can't differentiate that from a file that was in author/year/ and got moved to author/ in order to remove the year.
Using a special directory name for unset does avoid that problem.
The name would have to be configurable, since any value might be a valid valid for some type of metadata out there. I'd probably lean toward a default like '_' just because it avoids defaulting to an English word, and a name like '?' seems like asking for trouble with unsafe shell globbing.
Implemented this! Using the "field?=*" syntax described. With the directory configurable by annex.viewunsetdirectory
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
Notice:
_(unset dir) is showing after runninggit annex view 'dir-a/dir-b/dir-c/?=*'command. But I'm getting "path too long" on10.20241031in vadd.Case 2: When I do it like this (no paths too long errors)
It produces something like this:
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)
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 indir_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 ofdir_c(for those that aren't already have tags). But despite I specifiedtag?=*(notice the question mark), the "unset dir" does not appear.After fixing long paths and running:
it does exactly what I need, and produces:
Haven't tried to use it with
tag=*but for now it's even better as I'm mostly interested intag-aandtag-b.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 oftag-bbut nottag-c(_ = dir-c-children ∪ !(tag-a)).After even closer inspection,
_works as expected indeed.The reason why I was confused is that some folders with
tag-bwere appearing in_because this folder was containing.jpg.jpgprobably produced by accident or are thumbnails generated by some app.