On Wed, 27 Sep 2006, Matthew L Foster wrote: > --- Theodore Tso <tytso@xxxxxxx> wrote: > > > On Wed, Sep 27, 2006 at 05:12:41PM -0700, Matthew L Foster wrote: > > > > > > 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? > > > > No, it can't. In order to do that it would have to change the commit, > > and that would be rewriting history. > > Perhaps the actual change itself should not contain a "commit time", > only "local commit time" should matter or be tracked locally (if time > is tracked/matters any). To repeat from a previous mail, I am not > saying timestamps (local or other) should be tracked in a git > distributed way, quite the opposite, local commit time should be > tracked locally. What I think you want and what you should talk about is that you're interested into the "local appearance time" for a given commit and not "local commit time". Using that terminology is probably much less confusing in the GIT world. To do so you'll need a GIT command that doesn'T exist yet. Let's call it git-local-arrival. It could be defined as follows: SYNOPSIS git-local-arrival <committish> DESCRIPTION The command displays the time when given commit appeared in the local repository. Is that what you want? That's certainly something _I_ would be interested in. But such a command would have to do some commit graph walking, based on the recorded reflog data, (there is not much documentation about reflog unfortunately) to find out exactly when given commit actually was fetched into the local repository. While that would be perfectly acceptable to use on your own machine, I don't think it would be a good idea to let gitweb use it due to the computing cost required. But again that's something possible but for which there is currently no code. [ thinking out loud: maybe git-rev-list could provide that local appearance time quite easily though... ] Nicolas - 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