Jakub Narebski <jnareb@xxxxxxxxx> writes: > So if revs->limited is set (but not because revs->topo_order is set), > which means A..B queries, we will be still using the old algorithm. > All right, though I wonder if it could be improved in the future > (perhaps with the help of other graph labelling / indices than > generation numbers, maybe a positive-cut index). > > Do you have an idea why there is no improvement with the new code in > this case? I didn't get the impression that it would not be possible to improve the "--topo A..B" case by using generation numbers from this series. Isn't it just because the necessary code has not been written yet? In addition to what is needed for "--topo P1 P2 P3..." (all positive), limited walk needs to notice the bottom boundary and stop traversal. Having generation numbers would make it slightly easier than without, as you know that a positive commit you have will not be marked UNINTERESTING due to a negative commit whose ancestors have not been explored, as long as that negative commit has a higher generation number. But you still need to adjust the traversal logic to properly terminate upon hitting UNINTERESTING one, and also propagate the bit down the history, which is not needed at all if you only want to support the "positive only" case.
