Please describe the problem.
annex.genmetadata is off by default, which will potentially lose you a lot of timestamp metadata if you don't pay attention. It should be on by default.
What steps will reproduce the problem?
Add a file to a fresh annex, observe it has no metadata.
What version of git-annex are you using? On what operating system?
6.20180227 on Debian
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)
Yes I love it! (Except for its spotty timestamp support)
I think there are two potential problems with this change:
Bloat. If someone is not going to use that metadata, they may not want the overhead of attaching it to every file.
It's entirely possible that a user has chosen to use year/month/day metadata fields for their own purposes. Perhaps they are using it to keep track of the original publication date of files, and so would not want "wrong" values to be automatically added.
And that's essentially the reason why all parts of git-annex that deal with specific metadata fields are optional, so there's no default hard-coded semantics to the metadata fields.
(With the exception of git-annex importfeed, which always stores the itemid from the rss feed in the metadata, but only because it's needed to detect buggy feeds that change their item urls.)
Some reasons
annex.genmetadatashould not default to true: (1) ordinary git does not preserve file modtimes, probably on purpose: if you have some kind ofmakeprocess, you wantgit updateto cause updated files to have updated modtimes, not the modtimes from when the files were added to git, so thatmakecan detect the change and update downstream files; (2) as @joey noted, potentially wasteful bloat, especially for repos with many files; (3) two different copies of a file may have different modtimes, but all copies must have the same git-annex metadata, because metadata is attached to the key, which for most backends is computed from file contents.The WOM backend stores the modtime in the key, but then does not store checksums. If external backends are implemented, you could make one that includes both the checksum and the modtime in the key.
I agree with Ilya's points.
And it's unresonable to characterize this as data loss, because git itself does not store file timestamp data. Making such mischaracterizations does, however, cause me, as the maintainer, to wonder if this is a feature that is worth keeping, since I have no interest in descending that rabbit hole or fighting such accusations. Generally, going to the strongest possible argument, when requesting a change, is not actually your best move.
Closing this bug report.