Re: git and time

From: Matthew L Foster <mfoster167@yahoo.com>
Date: Sep 28, 2006, 02:29 UTC
Message-ID: <20060928022917.29678.qmail@web51011.mail.yahoo.com>
In-Reply-To: <20060928013611.GC7469@thunk.org>

--- Theodore Tso <tytso@mit.edu> wrote:

Show 9 quoted lines

> 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