On Mon, 25 Sep 2006, Jon Smirl wrote: > > When running fsck objects, does it verify that timestamps are ordered > in the same order as the dependency chains? No. In fact, it's perfectly normal that they aren't. Two machines with different timestamps will think time is different, and then one side doing a merge may have it's parents "in the future" from itself. You can't even solve it sanely: you can't change the other sides time-stamps after the fact, and correcting the _merge_ timestamp to be later than both parents is a fix worse than the problem, since it would tend to just perpetuate a buggy timestamp further down the line. So this is very fundamental. The first rule of distributed computing is: "There is no common time". Any distributed project that thinks such a thing exists is just fundamentally flawed, so I'd have been personally embarrassed by such a design decision. So the only thing that matters is always the dependency chain. We've occasionally discussed having "sequence numbers" or other things to make it easier to decide on partial ordering between commits without having to actually follow the whole dependency chain, but times and dates is _never_ a valid thing to use for that. > I am having trouble with a CVS repository where the timestamp ordering > and dependency order are in conflict. It would be best if git didn't > experience the same problem. It's not really a problem. The timestamps don't "matter". The only thing git really cares about is the dependency order. If commit timestamps aren't ordered, some of our programs may look at unnecessarily many commits because the heuristics use the (committer) timestamp as a way to guess which leg of a parenthood chain to take, but that's just a guess. And the authorship timestamp is never used at all, except purely for output. So they show up in the log messages, but you can think of them as nothing more than the commit commentary. Linus - 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