Re: git and time

From: Matthew L Foster <mfoster167@yahoo.com>
Date: Sep 27, 2006, 22:46 UTC
Message-ID: <20060927224651.26627.qmail@web51013.mail.yahoo.com>
In-Reply-To: <20060927215612.GB21839@spearce.org>

--- Shawn Pearce <spearce@spearce.org> wrote:

Show 12 quoted lines

> Because of the potentical for clock skew even on a single system
> you can't take much stock in a timestamp.  But with Git you can at
> least completely trust the commit graph, provided that you trust
> those who made commits before your own commit.  Of course this
> trust is only possible because the commit graph cannot be altered
> once a node has been added into it.
> 
> As such the commit graph is consistent between repositories (assuming
> they have the same head commits), but the timestamps of the reflogs
> within each will widely differ.  They could widely differ even on
> the same system due to ntpd updating the clock at the exact wrong
> moment for example.  :)

I am not arguing for git to try to achieve "exact" time just merely locally time consistent commit order. This might all just be a gitweb.cgi time display issue, it should be more impossible for a commit to appear as being made 2 days in the future and impossible for local time order to be out of sync with commit order. If each git repo used local time to track commits/merges you wouldn't have to worry if any remote git server's time was grossly misconfigured. Time doesn't need to be exact, all I am saying is each git repo should trust/prefer its local time rather than a remote git server's timestamp.

-Matt

__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com