Re: git and time

[Shawn Pearce <spearce@spearce.org>]

Matthew L Foster <mfoster167@yahoo.com> wrote:
> --- 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.

Git does has local time order, so long as the user doesn't screw
around with their clock.

Each time a commit gets made (or a merge gets performed) Git takes
the local system clock and dumps into the new commit as part of
the "committer" comment.  But as has been stated many times before
in this thread, this is no more trustworthy than the username and
email address also appearing in that "committer" line and its not
relied upon by Git.  Some interfaces may try to sort based on this
timestamp but only to help it break ties.  The dependency graph
always wins as that's always correct.

I have a Git repository from which I'm tracking an SVN repository.
Recently that SVN repository gave me "(no date)" as a datestamp.
Git converted that to Jan 1, 1970.  That commit has a parent and
has a child, both of which have sane timestamps.  But viewing this
in gitk or git log its obvious that the Jan 1, 1970 commit is in
the right position within the graph, it just has a timestamp that
I can't trust as its 36 years in the past.

There's nothing I can do about that timestamp.  It came from another
system that I have no control over.  But Git accurately recorded
what that other system provided it.  The "truth" here is that other
system provided a bogus timestamp.

-- 
Shawn.