Re: git and time

Matthew L Foster [off-list ref] 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? 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.