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

doc/bugs/Deleting_last_copy_of_files_doesn__39__t_mark_them_dead.mdwn

@@ -0,0 +1,47 @@
+I'm not sure if this is a bug per se but a small bother.
+
+In [deleting unwanted files](https://git-annex.branchable.com/tips/deleting_unwanted_files/) it is mentioned that you can use `git annex drop --force $file` to make it go away. But after that when fsck is run it will warn that there are no copies and that it should be marked as dead. And if it's deleted from the branch it will still complain if fsck is run with `--all`.
+
+Shouldn't they be marked dead automatically if the copy count reaches 0?
+
+Example:
+
+[[!format sh """
+$ git annex fsck 
+fsck test 
+  ** No known copies exist of test
+failed
+(recording state in git...)
+git-annex: fsck: 1 failed
+$ rm test
+$ git annex fsck --all
+$ fsck SHA256E-s16--c21f3ac6b5f6e45b1c0b292bcd5cc806298ecb033bc7030a6071e3c894d73054 
+  ** No known copies exist of SHA256E-s16--c21f3ac6b5f6e45b1c0b292bcd5cc806298ecb033bc7030a6071e3c894d73054
+
+  (Avoid this check by running: git annex dead --key )
+failed
+(recording state in git...)
+git-annex: fsck: 1 failed
+$ git annex forget --force
+$ git annex repair --force
+$ git annex fsck --all
+fsck SHA256E-s16--c21f3ac6b5f6e45b1c0b292bcd5cc806298ecb033bc7030a6071e3c894d73054 
+  ** No known copies exist of SHA256E-s16--c21f3ac6b5f6e45b1c0b292bcd5cc806298ecb033bc7030a6071e3c894d73054
+
+  (Avoid this check by running: git annex dead --key )
+failed
+(recording state in git...)
+git-annex: fsck: 1 failed
+"""]]
+
+From this, not even forget,fsck or repair can make this go away but only `git annex dead --key` which can be a pain to call it on a ton of different keys (there doesn't appear to be an option to batch mark them all as dead either).
+
+
+
+
+Additionally the key will still remain in the `git-annex` branch, I'm not sure about the internal optimizations in place but I'd assume leaving unused keys around in the branch can cause slowdowns when it's checked out/updated in repositories with a lot of add/update/delete activity.
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I'm using git annex to manage all my personal data, thanks for making such an amazing piece of software :)

doc/bugs/Deleting_last_copy_of_files_doesn__39__t_mark_them_dead/comment_1_234aa73f3463c35a0f3004c6524d0464._comment

@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 1"
+ date="2018-10-03T08:01:25Z"
+ content="""
+Regarding git-annex-dead:
+
+> This command exists to deal with situations where data has been lost, and **you know it has**, and you want to stop being reminded of that fact.
+
+Dead-ifying keys automatically could result in the situation where a key is marked as dead and the user doesn't (and wouldn't) know about it (until trying to use the file) because git-annex would never complain about it.
+
+Adding --batch support for `git-annex-dead --keys` would be good. I suggest making a todo for just that and/or for adding support for `git annex drop --force --dead`?
+"""]]

doc/git-annex-metadata.mdwn

@@ -23,11 +23,17 @@ this cannot be directly modified by this command. It is updated
 automatically.
 
 Note that the metadata is attached to the particular content of a file,
-not to a particular filename on a particular git branch. 
+not to a particular filename on a particular git branch.  More precisely,
-All files with the same content share the same metadata, which is
+metadata is attached to the key used for the file, which can reflect
+file contents and/or name, depending on the key-value backend used for the file.
+All files with the same key share the same metadata, which is
 stored in the git-annex branch. If a file is edited, old
-metadata will be copied to the new contents when you [[git-annex-add]]
+metadata will be copied to the new key when you [[git-annex-add]]
-the edited file. 
+the edited file.  Note also that changes to a file's git-annex metadata will
+not be reflected in the git log of the file, since they are stored on the 
+git-annex branch. To attach metadata to a particular path,
+rather than a particular key, use .gitattributes .
+
 
 # OPTIONS
 

doc/todo/option_to_add_user-specified_string_to_key/comment_1_9858fb711d788db96efa03c389a2ba52._comment

@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2018-10-02T17:38:10Z"
+ content="""
+Example of where the ability to add a string to key would help:
+annex.genmetadata stores year, month, and day metadata, from the file's modification date; but this will be silently overwritten if later other files with the same key but different modtime are added.  On the other hand, if I specified in .gitattributes that a random string uXXXXXX be included in the key, git-annex metadata would in effect become per-file, so one could attach metadata without worrying that it could get silently overwritten.
+
+An heuristic alternative is to add an option to metadata --get to use the field value from the time the file was committed, rather than the current value.  But this doesn't cover the case
+of two same-content files in the same commit.
+"""]]