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.