Re: Unresolved issues

Linus Torvalds wrote:

quoted

  When you run "git rev-list A..B C", and there is a commit in the chain
  between A and B whose timestamp is much older than its parent, sometimes
  we fail to mark C as reachable from A (hence not interesting) even when
  it actualy is.  This is very expensive to solve in general, and we are
  not going to introduce "generation number" field to the commit objects,
  so we may have to settle with a heuristic.

Here is the already posted heuristic that fixes both t/t6009 and the 
real-world case that triggered the whole discussion.
It's certainly not perfect, but I think it's likely an improvement on what 
we have now, and it should be robust in the face of the _occasional_ wrong 
date.
Now, if there are consistently totally bogus dates, the SLOP thing won't 
help, but ...

Ouch - I had always supposed that topology was king, and that the commit
dates were purely informational.  In particular the Perl history that I
produced in general takes a position of blatant and wanton disregard to
such consistency.

I can't find the other thread you refer to - is there a good summary of
the issues somewhere?  The test script is not very descriptive.

If timewise out-of-order commits are bad, perhaps git-filter-branch
should warn when it is creating histories whose topology disagrees with
their chronology... and also the user manual should probably describe this.

Sam