On Wed, Sep 27, 2006 at 05:12:41PM -0700, Matthew L Foster wrote: > Ignoring the separate issue of replication for a momment, can someone > respond to my time integrity question about whether a future version > of git could trust/prefer its local time rather than a > remote/sub/parent (non replicated) git server's timestamp? Yes, it could. But it would not involve rewriting the commit object or adding a new commit object (for reasons I hope have been adequately explained by Linus). Instead, an external mapping would be made between a commit SHA1 and a timestamp (or a (branch,sha1) pair and a timestamp). In fact, this is how reflogs work (but they make a map only when the head changes, not marking each commit that enters the repo). > How do we fix gitweb.cgi, ref-log? To "fix" gitweb, keep a database in each local repository as described above (either based on reflog, or one that is more comprehensive). Have gitweb report that date rather than the timestamp contained in the commit. Nobody has created such a patch; you can always try and see what the response is. > How useful is gitweb.cgi if timestamps are all over the place? It does Quite useful, according to many git users. -Peff - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html