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

added todo re: creating option to add user-specified string to key

Browse source
This commit is contained in:
Ilya_Shlyakhter 2018-09-26 03:02:23 +00:00 committed by admin
parent 3e84a055ea
commit 97ef9e1c4a
1 changed files with 13 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
doc/todo/option_to_add_user-specified_string_to_key.mdwn Normal file
View file

@ -0,0 +1,13 @@
Add a config (and gitattributes) option annex.userkeystring , such that git-annex-add (and calckey) will include this string in the key. If the string is 'UUID' then a uuid (or shorter random string) will be included instead.
From [[todo/support_longer_file_extensions]]:
"The way git-annex picks extensions doesn't need to be stable across all versions of git-annex, because it's only done when initially adding a file, and then the key, with whatever extension, is added as-is and git-annex does not care about the extension thereafter."
Then, for an MD5E key, the userkeystring can be included before the extension: MD5E-s0--d41d8cd98f00b204e9800998ecf8427e.USERKEYSTRING.txt .
Cleaner would be to add a field to the key, as in MD5E-s0-uUSERKEYSTRING--d41d8cd98f00b204e9800998ecf8427e.txt , if that wouldn't break compatibility.
This enables attaching metadata not to file contents, but to the file itself; or partitioning keys (and therefore key metadata) into namespaces. The downside is some loss of
deduplication. This loss may be acceptable. The loss can be mitigated for local repo and non-special remotes: after storing an object with e.g. MD5 d41d8cd98f00b204e9800998ecf8427e under .git/annex/objects, check if there is a symlink .git/annex/contenthash/d41d8cd98f00b204e9800998ecf8427e ; if not, make this a symlink to the object just stored; if yes,
erase the object just stored, and hardlink the symlink's target instead.