I know we can associate arbitrary metadata to files. I'd like to be able to sync remote specific metadata (say ip = 10.0.0.1) fields around. I was originally thinking of shoving this in the description but I am not sure that (a) it gets synced around and (b) it will scale well enough.
Then I thought we could use the key/value storage, but then the keyname would change with metadata changes so maybe that won't work...? Another option I thought of was to just throw stuff in a separate directory in the git-annex branch.
Thoughts? --anarcat
Well, git-annex uses remote.log for such data, and it ignores any extraneous fields, so..
remote.logis present only for "special remotes" - could i also use it for... well, "non-special remotes"?remote.logis empty or even missing in most of the git-annex repos I used, because i don't use the special remotes so much. could i still store information in that file even though it's not being used by git-annex?or could i just use
uuid.loginstead, which is present for all types of remotes?This is rather old, but I find it a good question. For example if I clone from a clone, the new clone will have metadata about the original origin - assuming annex was used - in the form of a uuid, but no way of tracking where that uuid came from or might be.
Last known paths might help, or some sort of ‘client-host’ metadata for each normal repo that’s recorded whenever a certain repo has others configured as its remotes. Specifically in an
A<-B<-Cconfiguration, B might register A as its host, and B as a client of A so that when B and A sync, B is added to A’s client list, or if B and C sync first, C is registered as B’s clients and can see that B has A as a host.