Re: kernel.org now has gitweb installed

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.