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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
