On Wed, Sep 27, 2006 at 10:04:04PM -0400, Sean wrote: > > I actually understand that and agree. All I've been saying is it > > (git or gitweb.cgi) should prefer the local timestamp rather than > > any "remote" timestamps for no other reason than to minimize the > > possibility of timestamps being grossly inaccurate. > > But any local time stamp would be a _lie_. The time stamp in the > commit records when it was actually created. And as Junio has > pointed out, hundreds of commits will typically arrive in a repo at > the exact same time. Your suggestion would have them all showing > the exact same time. That's not helpful, and it loses important > factual information. There are two issues here. Could a git tree record the local time that each commit entered the repository? Sure. Someone who wanted to hack up git so that it created a local db file associating the SHA hash name of the commit with when it arrived in its local repository. It would not be part of the "true" git repository information, and it could be something which is optional in the sense that if the information is lost, it's not the end of the world, vis-a-vis correct git functioning. The second question, though, is would it be *useful*? Presumably this would be an option, so the user could request to see the time when a commit hit a particular repository, as well as when the commit was first created --- or perhaps both. The problem though is that this could easily get confusing, since it adds a distinction (which repository am I talking to?) which normally doesn't exist in git. And it forces us to make explicit things that normally are kept hidden --- such as whether or not Linus does his work directly on the git tree which is exposed by master.kernel.org, or whether he does the work on his own local tree, and then pushes the changes to master.kernel.org. In git, we believe that all repositories are equal, and that any sense that a particular repository is the "master" or the "mainline" is strictly speaking, a matter of convention. What Matthew I think is asking for is direct support in git for that notion. So it *could* be done, but whether or not it is a good idea or worth the complexity is a different question. One could imagine a completely different protocol, which exported the contents of the hypothetical db database described above. So for maintainers that were *important*, and who were willing to make this information available, given a particular SHA hash of a commit, one could ask the question, "when did this commit first eneter your repository"? Matthew seems hung up on on desperately wanting to know this information as it relates to a particular repository --- Linus's. This is in fact different from when the commit hit the repository which is master.kernel.org which is why the local commit times on master.kernel.org wouldn't be useful. HOWEVER, if it was judged important enough, and worth the complexity that it would add to git, the ability to track when a commit entered a particular repository and the ability to export it via some kind of web interface certainly be implemented. Linus would then have to decide whether this was information he felt like making available to inquisitive seekers wanting to know this sort of info. - Ted - 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