Matthew L Foster <mfoster167@xxxxxxxxx> writes:
> Ok, I was wondering about that. In your example above the
> internally unnecessary timestamp will be from Linus' private
> repo, not master.kernel.org's?
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.
-
-
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