Re: Unresolved issues

[Sam Vilain <sam@vilain.net>]

Linus Torvalds wrote:
>>   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