--- 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. -Matt __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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