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