Re: git and time

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

Yes, and it is stronger than that. If somebody did a sata patch, sent that to Jeff over e-mail, and if the patch was accepted, Jeff will make a commit in his private repository, recording local time on his machine. Later Linus may pull from Jeff and the commit object is transferred during that.

To Linus, the time he first saw the commit was the time he pulled from Jeff, so being able to tell when it came into his repository may help him if he pulled from other people too and then suddenly realizes his sata disk does not respond at all.

He COULD say "it was working yesterday, I pulled from Jeff 3 hours ago, and then David 2 hours ago, I did not do my own development during that time. Did the breakage come when I pulled from Jeff or when I pulled from David?" ref-log would let him do something like:

	git checkout -b trythis master@{4.hours.ago}

to make sure the state before he pulled from Jeff was a working state and then still on the trythis branch he cuold do

	git reset --hard master@{2.hours.30.minutes.ago}

to see if the state after he pulled from Jeff was broken.

	Side note: in reality he does not have to care.  He can
	just bisect it without using any of his "pull boundary"
	time.

So that was discussion about the time Linus first saw the commit. What about us, general public? Until Linus pushes out the merge result, we would not see it. Anyway, eventually he will push his tip of the branch out to kernel.org and rsync will mirror to public git:// and gitweb machines.

What's the local time the general public sees the commit for the first time? It's (forgetting for now the rsync mirroring delay) the time Linus pushed the tip of the branch out. Along with all other hundreds of commits he acquired since the last time he pushed his tree out.

It is sometimes useful to know when a particular commit has become available to the general public. I do not think anybody is denying it.

But it is a completely separate issue if it is useful to label the commits that happened to be pushed out together at the same time with the same timestamp on the gitweb short-log page (or short-log corner on the summary page). Most of the time you will see commits pushed out by the same push operation and having exactly the same timestamp. That's not very useful way to present the information.

	Side note: some commits arrive kernel.org machine
	earlier than others because Linus does not have infinite
	bandwidth to kernel.org, but these hundreds of commits
	become visible to the general public exactly the same
	time, because we send them and as the last operation we
	update the tip of the branch.  So you cannot even say
	"record the time down to the second they arrived the
	kernel.org repository" -- until the branch tip is
	updated the general public cannot see them so the
	arrival time (mtime of .git/objects/??/???...?? files)
	does not even matter.

If somebody feels strongly about it, I would suggest adding that information on the commit page of gitweb, where the program needs to deal with only one commit. That would help somebody who is interested in _one_ particular commit and wants to know when it has become available to the general public.

-