--- Theodore Tso <tytso@xxxxxxx> wrote: > 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? > > No, it can't. In order to do that it would have to change the commit, > and that would be rewriting history. Perhaps the actual change itself should not contain a "commit time", only "local commit time" should matter or be tracked locally (if time is tracked/matters any). To repeat from a previous mail, I am not saying timestamps (local or other) should be tracked in a git distributed way, quite the opposite, local commit time should be tracked locally. Replication is a separate issue if I understand git any. Please correct me if I misunderstand: the kernel.org gitweb.cgi linux repo time inconsistencies happened when Linus pulled into his _private_ repo from a remote git server with misconfigured time, _not_ when he later replicated those errant timestamps from his private repo to the public kernel.org one. I don't care nearly as much about replication not being time aware, I care about a _merge_ from a remote misconfigured git server making timestamps inconsistent with commit order. Using/prefering local time could solve this but perhaps I am the only one that thinks local time is most important. -Matt __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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