I use git-annex to store my music collection, which includes many albums I've ripped but don't like, as well as many albums I do like to listen to regularly but can't put on all my devices because of storage space limits. Previously I've used a Now Playing directory to track this, with copies of all the symlinks, but when I edit files (to correct file tags or whatever), things can get out of sync, so now I'm trying to use metadata instead. I was thinking to add a NowPlaying=machinename scheme and then on each machine I can git annex get --metadata NowPlaying=machinename.
While migrating to this scheme, I've discovered a few places where a file wasn't in Now Playing when I expected it to be. A good example is that some songs exist both on an artist's album as well as a compilation album, and I've dropped the track from the compilation album because I already had it on the artist's album.
This has made me think that it would be nice to track changes to metadata, the same way we do with git commits on the files themselves. Right now this is almost possible using the git-annex branch. However:
- Every change to metadata just has the commit message "update". It would be nice if I could pass a commit message using something like
git annex metadata -s 'NowPlaying-=machinename' -m "This already exists on Artist - Album". - Looking at the metadata history for a given file requires dereferencing the git-annex symlink and knowing some git-annex internals. It would be nice if there was a
git annex metadata log <filename>command.
From reading the documentation about metadata driven views, it seems almost like #1 would be possible using views and doing a git commit myself, but that still just generates an "update" message on the git-annex branch. Even if it did work, using git annex view 'NowPlaying=*' excludes all files that aren't tagged with any machine, which makes adding new files harder.
What do you think? Is this abuse of the git-annex branch? Would this interfere with caching database?
I don't see the benefit to having custom commit messages for metadata changes. The changes are there in machine-readable format, so why involve a human?
I agree that it would be useful to have a way to look at the metadata history, much as
git annex loglooks at the location history.Indeed, a lot of
git annex logcould be reused;getAllLogandgetKeyLogare the hard part and would be reusable for metadata logs. The result might be something like this, when run on a file "foo":Note that git-annex log is necessarily slow when run on a lot of files, because it has to run a git command per file to get the log.
git-annex log --allshows a fast stream of changes from newest first, but displays the git-annex key that was changed, not a filename. A version ofgit annex logfor metadata would have these same limitations.Would this help with your use case?
I agree that a human-readable commit message is probably the wrong place to put it. I didn't know about
git annex logbut that sounds helpful. I wouldn't need it to be fast -- it would be for rare interactive use.I'd like to not just be able to see what changed with the metadata but store a description of why as well, which is why I thought of commit messages. Would your design support that?
Thanks for your consideration.
While git-annex does now let annex.commitmessage be set to specify a commit message, it seems to me that you could include your reason for the metadata value as yet more metadata. Ie:
And a metadata log display would then naturally include those messages next to the change they describe.