Re: git and time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Matthew L Foster <mfoster167@xxxxxxxxx> wrote:
> --- Linus Torvalds <torvalds@xxxxxxxx> wrote:
> 
> >  - so I replicate my home machine tree to the one on master.kernel.org, 
> >    and now others can see it.
> > 
> > When did the merge happen? It happened at 8:30 on my machine, and that's 
> > what is recorded. End of story. No ifs, buts, maybes about it. That's the 
> > only time you can _ever_ see for that merge.
> 
> Ok, so it's more complex because of the workflow issue of delayed/pseudo mirroring/replication
> between private and public repos?

No.  Its no different than anything else.  Linus' personal repository
is just as visible to you as say Andrew Morton's personal repository
(read: neither one is visible to you).  Therefore the date/time
that a given commit hits either one of those repositories is only
of interest to the people with direct access to it.  Which is Linus
and Andrew respectively.  And probably nobody else.

When Linus pushes all of those merges out to kernel.org those
commits are arriving at "his" kernel.org repository at a date/time
that is absolutely after when they first arrived in Linus' personal
repository.  Note that the kernel.org repository is a completely
different repository from Linus' personal work repository!

But due to clock skew, time zone differences, etc. between systems
those commits may actually appear to arrive at kernel.org before,
at the same time as, or after they arrived on Linus' personal system.
:-)

> This cloning/replication is not done through git?

I don't know.  I'd wager Linus is probably using Git to push changes
to some repository on a master system behind the kernel.org domain
name, and that master then gets replicated out to mirror systems
through some form of replication.

> Are you saying it's impossible for master.kernel.org's git to track the local time of each
> commit/merge/replication? Perhaps replication time is precisely what should/could be tracked
> (locally)? 

I don't think the replication time is really important here.  If it
was then Git should be used for the replication of Git repositories
being mirrored on kernel.org.  I doubt you'd get every mirror
operator to do that however.

> From an integrity or at least gitweb.cgi's viewpoint it seems very important to me that commit
> order also be per repo consistent with time order.

I'm not sure I follow you.  Time order has nothing to do with
anything.  That's largely been the entire point of this thread.

Because of the potentical for clock skew even on a single system
you can't take much stock in a timestamp.  But with Git you can at
least completely trust the commit graph, provided that you trust
those who made commits before your own commit.  Of course this
trust is only possible because the commit graph cannot be altered
once a node has been added into it.

As such the commit graph is consistent between repositories (assuming
they have the same head commits), but the timestamps of the reflogs
within each will widely differ.  They could widely differ even on
the same system due to ntpd updating the clock at the exact wrong
moment for example.  :)

-- 
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]