Re: git and time

From: Shawn Pearce <spearce@spearce.org>
Date: Sep 28, 2006, 00:23 UTC
Message-ID: <20060928002327.GA22593@spearce.org>
In-Reply-To: <20060928001241.62887.qmail@web51013.mail.yahoo.com>

Matthew L Foster <mfoster167@yahoo.com> wrote:

Show 8 quoted lines

> 
> 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? How do we fix gitweb.cgi, ref-log? How
> useful is gitweb.cgi if timestamps are all over the place? It does not make sense that commit
> order is currently out of sync with time order in the main linux kernel tree git repo on
> kernel.org. Why must each and every repo be dependent on time being set properly on all other git
> servers? How useful is change history or commit order without some concept of (local) time order?

Dependency order is all that matters.

It doesn't matter if K. Hacker makes a bug fix at 8 am his local time or 3 days ago. All that matters is that K. Hacker made it by changing version A to version B. Therefore commit B (containing the bug fix) depends on commit A and only commit A (which may in turn depend on commit A^, etc.).

That dependency in turn implies that you can't have bug fix B without whatever feature/bug fix was A, and what that dependend on, etc. Thus you know you have some particular chain of events as a result of having B. That's all that's interesting.

It _may_ matter to me that I received commit B (and maybe commit A) at 3 pm my local time. It may not.

In general I don't care too much about when a commit comes to me and when it doesn't or when it was written, though I do look at

	git log next@{yesterday}..next

to see what Junio has pushed out recently. Since I tend to fetch only once per day (and usually around the same time of day) this works reasonably well.

-- 
Shawn.