Hi :-) >> You would also consider things such as renames.
If I remember correctly, Git does not keep track of renamed files across revisions (yet?) There’s just a simple heuristic to detect renames which is based on the similarity of the files. But maybe I’m wrong here. Are here some Git experts around? I would simply rely on Git’s existing functionality (git blame). This would allow us to keep the required code for password-store as small as possible. And as I said, I assume that 'git blame' does not support renamed files yet. But this might come as a new Git feature in the future. By building this feature around ‚git blame‘ we could profit from this later on.. >> I think that this isn’t a great feature because it is easy to misunderstand >> it. If you actually >> want the time the password itself was created you would need more >> metadata, for example `pass generate` could add a "Generated At" >> property. As already pointed out: an additional tag must be kept in sync. We have a nice version control system which does exactly this for us :-) Adding more stuff like tags, just adds complexity. I like it the KISS style.. >> But I think that assuming that the last time a file was >> updated is equal to the last time a password was changed is a poor idea. It’s not the modification date of the file. We are talking about the modification date of the first line. To add some related thoughts: - is there a timestamp in the GPG metadata of the encrypted file? - does Git keeps track of modification / access timestamps? (I don’t think so) - because I’m also interested in the point in time where I used (decrypted) the password the last time. Cheers, Steffen — Steffen Vogel Robensstraße 69 52070 Aachen Mail: [email protected] Mobil: +49 1575 7180927 Web: http://www.steffenvogel.de Jabber: [email protected]
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Password-Store mailing list [email protected] http://lists.zx2c4.com/mailman/listinfo/password-store
