Matthew L Foster wrote:
How can git be said to keep an accurate record of history if time is uncertain?
Because git doesn't care about timestamps. It stores them as comments (albeit auto-formatted comments) and relies on the dependency chain to provide history.
In the same way that contributors are expected to write clear and concise commit-messages, they are also expected to keep their system clocks somewhat in sync. Sometimes one or the other fails, and this is as inevitable as it can be annoying (although commit-messages along the line of "fixed some bugs causing some random crashes" for a commit that touches 2384 lines are indefinitely worse than a bad timestamp).
What's beautiful about git is that it's designed to present a correct history even if random-contributor-X's system clock is out of sync with the rest of the world, as it inevitably will be at one point or another. It handles content, and the order in which each piece of content was added/removed/mutilated/transformed into something else, and it does a good job at that.
All that aside though, would you rather have that fix pronto with a bad timestamp, or three days later when the contributor had time to set up ntp properly?
-- Andreas Ericsson andreas.ericsson@xxxxxx OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 - 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