Matthew L Foster wrote: >> 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. > > Ok, the word "history" in the context of git primarily means the order of changes not the when? > Would it be a conceptual or technical issue for git to directly track the local time of > merges/changesets? It is tracking the local times of each change as it is added to the dependancy chain. This chain then moves about between repositories carrying its stamp with it. When we merge a set of changes into a trunk such as Linus does that merge will be stamped by him saying when he merged it. So there is plenty of time stuff in there. Of course none of it tells you when the kernel you are running has it in. The only way to know that is to know when the thing was released, under what version#, and what version you are running. Now when we make a signed tag, doen't that make a new object too and I assume that has a tagged date in it. That time might really actually mean something and a fix's relation ship to those tags might also mean something. -apw - 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