Re: git and time

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

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