Re: Unresolved issues

From: Sam Vilain <sam@vilain.net>
Date: Mar 19, 2008, 22:48 UTC
Message-ID: <47E19833.60402@vilain.net>
In-Reply-To: <alpine.LFD.1.00.0803171853180.3020@woody.linux-foundation.org>

Linus Torvalds wrote:

Show 13 quoted lines

>>   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