Matthew L Foster <mfoster167@xxxxxxxxx> wrote: > --- Shawn Pearce <spearce@xxxxxxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html