On Thu, Sep 7, 2017 at 3:11 AM, Jeff King <peff@xxxxxxxx> wrote: > On Thu, Sep 07, 2017 at 11:50:25AM +0200, Paweł Marczewski wrote: > >> Thanks. Any plans to fix that? Or is there a way to turn off this heuristic? > > I don't think there's a way to turn it off for `rev-list`. Merge-base > computations are more careful, so you could determine the correct > endpoints that way. But when you fed them to `rev-list`, it would hit > the same run of skewed commits. > > We've discussed storing true generation numbers in the past, which would > make this optimization more robust, as well as allow us to speed up many > other traversals (e.g., the "tag --contains"). It's something I'd like > to revisit, but it's not at the top of the pile. (We just had an office discussion if this is part of the hash transition plan, i.e. have a field in the commit object to contain its generation number. and as I think the generation numbers would lead to fast and correct behavior unlike the current heuristic which is only fast, I would try to make a strong point actual generation numbers inside commit objects) > > In the meantime, it would probably be possible to write a patch that > conditionally disables the optimization. But it would mean all of your > rev-lists run a _lot_ slower. > > -Peff
