From: Matthew L Foster Date: Thu, 28 Sep 2006 02:29:17 GMT Subject: Re: git and time Message-ID: <20060928022917.29678.qmail@web51011.mail.yahoo.com> In-Reply-To: <20060928013611.GC7469@thunk.org> --- Theodore Tso 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