Re: kernel.org now has gitweb installed

quoted

quoted

quoted

quoted

"LT" == Linus Torvalds [off-list ref] writes:

LT> So what you can do is:
LT>  - if there is one parent, just always walk straight down
LT>  - if it's a merge, add the parents _in_date_order_ to the list of things 
LT>    to do, and then pop the most recent one.
LT> Really. You say that dates don't matter, but they _do_ actually matter a
LT> lot more than "remote/local" does. At least they have meaning.

On a related topic, I have two questions on commit objects.

1. Currently, commit-tree does not seem to verify that all its
   parent SHA1's actually name valid commit objects.  Is this
   intentional?

I cannot see a good practical reason to commit a new version
that claim to be descendant of some SHA1 you know exists in
somebody else's tree, without actually having that object also
in your SHA1_FILE_DIRECTORY.  Otherwise how did you merge with
it in the first place?  For that reason, I expect the answer to
this question to be "no it was just being lazy.  Go ahead if you
really care."

2. Assuming that we do want to enforce that parent fields of a
   commit object name valid commit objects, is it OK to also
   require that the commit timestamp of a child object is not in
   the future relative to any and all of its parent commit
   objects (I'm talking about the timestamp of committer field
   not author field, although your e-mail patch acceptance
   procedure seems to be giving it the same timestamp right
   now)?

I have been wondering if imposing these two requirement has some
negative effects, but I do not offhand see any.  And these
requirements may make implementation of git log viewer simpler
when the user specifies "I want to view commit between these
ones---give me a linearlized list of commits."  When following
the ancestor chain from the current top, we can immediately stop
upon seeing a commit made before the timestamp of the named
bottom one.

On Thu, 2005-04-28 at 14:21 -0700, Junio C Hamano wrote:

2. Assuming that we do want to enforce that parent fields of a
   commit object name valid commit objects, is it OK to also
   require that the commit timestamp of a child object is not in
   the future relative to any and all of its parent commit
   objects

No. Time is utterly meaningless -- it's perfectly normal for clocks to
be out of sync. We really don't want to fall into the trap of assigning
any meaning to the timestamp.

-- 
dwmw2

On Thu, 2005-04-28 at 14:21 -0700, Junio C Hamano wrote:

"I want to view commit between these ones---give me a linearlized list
of commits."  When following the ancestor chain from the current top,
we can immediately stop upon seeing a commit made before the timestamp
of the named bottom one.

This absolutely must not be timestamp based. If I ask for a list of
commits before 2.6.12-rc3 and 2.6.12-rc4 I _really_ want to see those
commits which happened before 2.6.12-rc3 but in a remote tree which was
only later pulled. That's what 'rev-tree AAAAAA ^BBBBBB' already gives
you.

-- 
dwmw2

On Thu, 28 Apr 2005, Junio C Hamano wrote:

1. Currently, commit-tree does not seem to verify that all its
   parent SHA1's actually name valid commit objects.  Is this
   intentional?

No. Me lazy. I think we should check as many _cheap_ things as possible,
and checking whether a parent at least superficially looks like a real
commit object is certainly cheap.

2. Assuming that we do want to enforce that parent fields of a
   commit object name valid commit objects, is it OK to also
   require that the commit timestamp of a child object is not in
   the future relative to any and all of its parent commit
   objects (I'm talking about the timestamp of committer field
   not author field, although your e-mail patch acceptance
   procedure seems to be giving it the same timestamp right
   now)?

No, this is not ok. Clock skew is real, and somebody may have a 
misconfigured machine. Being careful about integrity is good, but trying 
to enforce time flow in a distributed environment is just being anal.

Maybe a warning.

		Linus

* David Woodhouse [off-list ref] [2005-04-28 23:23]:
 

No. Time is utterly meaningless -- 

This is fundamentally wrong. Space-time and causality has a *very*
important meaning.  If don't use this information (directly or
indirectly) in your data modell or history graph you do something very
stupid. You simply won't optimize for the common case because you won't
scale with the fundamental physical laws of information exchange and
syncronisation, you just kind of break space-time-symmetrie. Ever
compared feynman diagrams to merge diagrams?

it's perfectly normal for clocks to be out of sync.

Yes even special relativity just boils down to "there is no absolut
simultaneity". So what? 

I'll predict if you break causality your kernel will suddenly
destabilize and explode like a nuclear bomb ;-)

Gerhard