Matthew L Foster <mfoster167@xxxxxxxxx> writes: > Ignoring the separate issue of replication for a momment, can > someone respond to my time integrity question about whether a > future version of git could trust/prefer its local time rather > than a remote/sub/parent (non replicated) git server's > timestamp? This must be a trick question. git does not trust _any_ timestamp, so there is no local "rather than" remote. So, no there is no chance for that. Having said that, what Porcelains like gitweb and gitk do are completely different issue. I already outlined how you can do that using reflog last night, so I am not going to repeat it here. Also Linus stressed that why the "order that commits appeared on a particular branch in one particular repository" is strictly local issue today at least three times, and I hope everybody understood it by now. As Shawn said in a nearby thread, in a public and prominent repository like kernel.org repository it may sometimes be interesting and useful to know when each commit became available on each branch. I am reasonably sure that it would not however make gitweb output easier to read to order its output by that timestamp. Linus pulls from subsystem maintainers all the time and one pull may bring in dozens of commits, and they will get the same timestamp if you did so. Actually it is worse than that. He tends to batch, so he would have many such pulls and patch applications in his private repository, perhaps over a few hour, but the result will be pushed out to kernel.org with one push operation. To show the "truthful" time, your gitweb would give the timestamp of that push operation for hundreds of commits pushed out during that operation. I do not personally think that would be useful at all. And I happen to know how expensive to teach gitweb to produce such an output, so I would not seriously suggest anybody to try it. Can we please close this topic? - 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