don't copy old date metadata when adding new version of a file

When adding a new version of a file, and annex.genmetadata is enabled,
don't copy the data metadata from the old version of the file, instead use
the mtime of the file. Rationalle being that the user has requested to
generate metadata and so would expect to get the new mtime into metadata.

Also, avoid warning about copying metadata when all the old metadata is
date metadata. Which was rather the harder part.

This commit was sponsored by Boyd Stephen Smith Jr. on Patreon.

doc/bugs/if_annex.genmetadata_is_true__44___modification_metadata_is_imported_from_older_file_versions_after_unlock+add.mdwn

@@ -20,3 +20,4 @@ output: `Copied metadata from old version of bar to new version. If you don't wa
 ### What version of git-annex are you using? On what operating system?
 6.20180227, various Linuxes.
 
+> [[fixed|done]] --[[Joey]]

doc/bugs/if_annex.genmetadata_is_true__44___modification_metadata_is_imported_from_older_file_versions_after_unlock+add/comment_1_b215c8ce0f2094a116672572951b19fc._comment

@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-04-04T16:51:36Z"
+ content="""
+This happens in Annex.MetaData.genMetaData. First it copies
+metadata from the oldkey to the new key. Then it
+calls addMetaData on the dateMetaData of the file's mtime.
+
+In dateMetaData, there's a `filter isnew`, which makes
+it filter out any of the date fields that already exist
+in the metadata of the new key.
+
+This was done intentionally, see 
+[[!commit 8d5158fa3151be4c7fc698b96ed887b43ac48769]]
+But that's lacking an explanation of why it was done.
+
+Note that dateMetaData is also used in Command.ImportFeed
+to convert a itempubdate into year and month metadata.
+But changing its behavior to override old dates 
+would not change that code path.
+
+So, I don't see a problem with making this change, and have gone ahead and
+done it.
+"""]]