mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2017-05-09 13:08:03 -04:00
commit 4025a92527
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 39 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

21
doc/todo/Bidirectional_metadata.mdwn Normal file
View file

@ -0,0 +1,21 @@
In one of my annexes I will g-a-add a (e.g.) zip file, extract and g-a-add its contents and then set metadata on "each side"..
git annex metadata -s extracted_from+=$key_for_original.zip files_from_zip/
git annex metadata -s extracted_to+=$key_for_file1 original.zip
git annex metadata -s extracted_to+=$key_for_file2 original.zip
git annex metadata -s extracted_to+=$key_for_file3 original.zip
git annex metadata -s extracted_to+=$key_for_file4 original.zip
This means that if the content for a file in files_from_zip/ is lost, you can easily find that it came from original.zip (which may not be lost) *or any other zip in that annex that also contains that file*.
I was wondering if this would be worth building in?
git annex metadata --fromto original.zip files_from_zip/
There are other situations this is useful (and I use), for example, when I convert an annexed file to another format, I record the "source" and "target" keys against each other. I suppose a very general name would be:
git annex metadata --parentchild original.zip files_from_zip/
git annex metadata --parentchild original.wav compressed.flac
git annex metadata --parentchild original.svg compressed.png
and this would set 'parent' and 'child' metadata respectively.

8
doc/todo/Bidirectional_metadata/comment_1_9974d17e407fab14b12399016d3d66c2._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="CandyAngel"
avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
subject="comment 1"
date="2017-05-09T14:25:50Z"
content="""
It could also be possible to extend 'whereis' (maybe with a '--check-metadata' option?) to let the user know that *some* version (source or derivative) may be available.
"""]]

10
doc/todo/Configuring_metadata_view_filenames/comment_3_dd7aa7560412d4589d2fc28eb978a71e._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="CandyAngel"
avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
subject="comment 3"
date="2017-05-09T10:05:14Z"
content="""
> But that would make memory use scale with the number of files in the view, which I'd prefer to avoid..
This sounds like another use case for bloom filters :)
"""]]