Matthew L Foster <mfoster167@xxxxxxxxx> 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.
-
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